Recordings,
not rows.

Give agents signal evidence to reason with.

An investigation agent can search your recording archive before it answers: “Have we seen a signal like this before?” MorletDB supplies matching intervals and their original samples. Your application connects them to analysis tools, maintenance notes or experiment records.

Integration pattern using existing SQL primitives. Detection models, agent orchestration and machine controls are supplied by your application. The bundled MCP server only reads; try it with Claude in the seismic and machine demos. Agent and anomaly-detection effectiveness have not been evaluated; similarity alone does not establish normality, a fault or its cause.

From a similar shape to the original evidence.

Append. Search. Read.

Store a recording, find similar intervals, and inspect the original samples. The same SQL connection carries you from measurement to result.

-- Append at the recording’s next sample offset.
SELECT morlet_append_chunk(
  'public.getting_started', 'run-a', 0,
  ARRAY(SELECT sin(i::float8 / 8)
        FROM generate_series(0, 8191) AS i ORDER BY i)
);

-- Search a stored interval with a metadata filter.
SELECT * FROM morlet_search_envelope_interval(
  'public.getting_started', 'run-a', 0, 4096,
  '{"asset":"spindle-1"}'::jsonb, 10
);

-- Read original samples from an interval.
SELECT * FROM morlet_read_interval(
  'public.getting_started', 'run-b', 0, 4096
);

Illustrative SQL calls, not a live database. Create the collection and recordings before appending, then explicitly build envelopes before searching. The guide contains the complete runnable sequence.

Works with

Each entry is a documented integration you can run: follow it for the example, its scope and how it was verified (CI, release trial or manual run).

Names are shown as text; listing indicates a documented integration only and does not imply endorsement, partnership or certification. All names and trademarks belong to their owners (notices).

Bring your recordings to PostgreSQL.

Run the prebuilt release image (PostgreSQL 17 with pg_morlet, no compiling), try the Docker walkthrough with synthetic data, or build the extension with Rust and pgrx. PostgreSQL 17, 18 and 19 are supported by the compatibility matrix. Release images and paper benchmarks use 17. For an existing PostgreSQL 17 or 18 server on Debian, install the release’s package (amd64, arm64; installed with apt and tried before each release). PostgreSQL 19 (release candidate 19rc1) builds from source; images and packages for 19 follow 19.0. PostgreSQL 19 compresses large values with lz4 by default; MorletDB pins its sample and envelope columns to pglz, so storage is byte for byte the same as on 17 and 18 (compatibility).

docker run -d --name morletdb -e POSTGRES_USER=morlet -e POSTGRES_PASSWORD=change-me \
  -e POSTGRES_DB=morlet -p 127.0.0.1:54329:5432 -v morletdb-data:/var/lib/postgresql/data \
  ghcr.io/merkhet-io/morletdb:0.3.14-alpha.1
docker exec morletdb psql -U morlet -d morlet -c "CREATE EXTENSION pg_morlet"

The release image is Linux amd64 and arm64 and does not include pgvector (needed only for indexed probe search). Or try the walkthrough with synthetic data:

git clone https://github.com/merkhet-io/morletdb.git
cd morletdb
docker compose run --rm walkthrough

Requires Git and Docker Compose v2. The first run builds the extension and uses synthetic recordings. pgvector is optional for indexed probe search and is not included in this walkthrough. Developer alpha.

When your application needs to investigate signals.

Use MorletDB when you have uniformly sampled recordings (single channels, channels at different rates grouped into acquisitions, or synchronous groups sampled at the same instants), want to find similar intervals, and need to inspect the original evidence in its context.

Use cases beyond the evaluated seismic and appliance-current retrieval (N1) are proposed applications. MorletDB does not provide automatic diagnosis, speech recognition, resampling or multichannel similarity search.

How MorletDB looks at a signal.

A fault rarely shows in one reading. It shows as a shape over time, a knock that rings out, and as energy in one frequency band at that moment. In the picture, both similar events rise as peaks in the same band.

1. Recording. Samples on a fixed clock: start and rate are stored once, each time follows exactly.t_n = t₀ + n / f_s
2. Envelope. The signal’s loudness over time, the magnitude of its analytic signal. Similar events share it even when their oscillations don’t line up.e(t) = |x(t) + i·ℋ{x}(t)|
3. Search. Compare envelopes, allowing a small time shift τ, and return the original samples of the best matches.d(q, w) = 1 − max_{|τ| ≤ L} corr(e_q, e_w(· + τ))

Questions like have we seen this before? are about intervals of a signal; this is the primitive that answers them.

What you don’t have to build.

A general time-series database stores rows of timestamped values. MorletDB stores recordings, so the work around waveforms that you would otherwise build yourself is part of the database.

This table compares designs, not measurements, except where noted (B3, S1, X1, X2). Time-series databases differ, and several offer some of these: TimescaleDB runs inside PostgreSQL, and many keep roll-ups. For counters, KPIs and dashboards a general time-series database remains the better fit.

Where MorletDB fits.

Most time-series systems are built for rows of readings: metrics, events and analytics. MorletDB is built for the high-rate recordings behind them, and it runs inside PostgreSQL. The quadrant shows what each system is designed for and where it runs, from its own documentation; it is not a ranking. “Inside PostgreSQL” means running in a PostgreSQL server; CrateDB accepts PostgreSQL clients through PostgreSQL’s wire protocol but is a separate database server.

Use them together. If you already run CrateDB, TimescaleDB or a historian for plant-wide readings and dashboards, keep it for that. Store the vibration, current and acoustic recordings behind those readings in MorletDB, and link the two by asset and time.

Capabilities as documented for the versions listed; resend behaviour as measured in the benchmarks, where all measured results are. Names are shown as text and imply no endorsement.

Smaller archives. Faster evidence.

Every result below comes from a protocol frozen before measuring, on real recordings, with every sample read back bit for bit. Each comparison reports its losses in the linked results. Storage is compared like for like: MorletDB’s whole database (161 MiB, of which 149 MiB sample data; 163 MiB with chunk summaries, on by default since 0.3.7-alpha.1) against each database’s data on disk. B3’s headline ingestion rates use asynchronous commits, with the durable figures alongside; the small-machine studies X1 and X2 measure durable ingestion with search features, so their rates are lower by design.

The storage advantage comes from coding samples on their value grid (ADC counts, calibrated sensors, fixed decimals), which MorletDB detects automatically, with no calibration step to declare; signals without any value grid compress less well. Codecs at default settings unless stated.

Against time-series databases

The same 101.6 million samples of bearing vibration and motor current, one machine, identical containers, protocols frozen before measuring, every sample read back bit for bit. Each dot is one database on one measure, as a multiple of MorletDB’s figure, measured in one session with the two databases loading alternately; hover a dot for the values, open a tab for every number and its conditions.

Exact similarity search, 3.2–3.7× faster, same answersConfirmed · E7

Exact search compares a query with every stored window and returns the guaranteed nearest intervals. From SQL 0.3.3 a fast screen with a rigorous error bound skips windows that cannot be among the nearest, and only the rest are scored exactly. On galleries of seismic event windows from 0.23 to 1.03 million windows, every result list was identical to the previous path, bit for bit, on 100 of 100 queries per gallery.

Evaluation E7, protocol frozen before timing; all three paths ran in the same session on the same machine, with a desktop workload running (5-minute load about 5), so absolute times are higher than on an idle machine and only the within-session ratios are comparisons. Exact search reads every eligible window, so its time grows with the archive; probe search uses an index. Which one to call: which search to use. Full results: E7 results ↗ · frozen protocol ↗.

Built to run at the edge.

Waveforms are recorded next to the machine, and that is where MorletDB can keep them: on an industrial PC, an edge gateway or a NUC beside the line. It is a PostgreSQL extension with a small footprint, stores every sample exactly, and keeps search, statistics and context on the device, so an engineer or an agent can investigate locally without shipping raw data to the cloud first. To buffer data at the machine, Akhet, a separate collector from the same maintainers, commits MQTT messages and Modbus TCP registers to a local spool before acknowledging them and replays them into MorletDB later; process crashes are tested, power loss not yet. Container images are published for x86-64 and arm64.

Next to a machine there is no database administrator. tools/steward runs the rebuildable upkeep (envelopes, summaries, roll-ups, verification, statistics) in one budgeted loop, only when the machine is not busy, records every action and shows one plain status. At the disk reserve it holds ingest: appends fail with a clear reason (SQLSTATE 53100) before PostgreSQL runs out of space, and resume when space is free. Its role cannot remove stored samples; changes to stored samples and extension updates are plans that a second person approves.

Tested by filling a real disk on a Raspberry Pi 3B+: new recordings were refused at 295 MB free (300 MB reserve), with no PostgreSQL write error; 14.5 s after space was freed, recording resumed on its own, and every acknowledged sample read back bit for bit.

Not yet tested: power loss and weeks of operation. Disk-fill results ↗ Blog: self-driving Postgres on the edge

Not every site can send or keep every sample. For narrow uplinks and long retention we tested a compact approximation: a wavelet transform keeps the largest coefficients, which is where short impacts and onsets live, coded to a fixed byte budget per window. It would travel next to the exact data, never replace it as evidence. In a study frozen before its confirmation data were used, at 0.1 bytes per sample, about a fifteenth of the lossless size:

What it means for the product: a strong long-retention and narrow-uplink tier for vibration from bearings and machine tools, not the only tier for trigger-based event detection or short cycles, where exact data or downsampling is the better choice.

Held-out data: XJTU-SY and Paderborn bearings, PyScrew screwdriving (s02), Chilean seismic stations (2021), two Bosch CNC milling machines. Relative error of the reconstruction, actual coded sizes, Python prototype; two recorded deviations, neither changing a decision. It is not part of a release. F2 results ↗ Report 3 (PDF, draft 0.3) ↗

Edge PCs and gateways usually have more cores and memory than these tests. Not yet tested: weeks of continuous operation, power loss, and specific industrial hardware. X1 container-limit study ↗

A portable format for lossless waveforms.

A MorletDB recording can also be one file: every sample exactly as measured, with its sample rate, unit, channel, start time and metadata, in an ordinary SQLite file that opens on every platform and in practically every language. The file and the server use the same chunk format, so a recording moves between the machine, a laptop, an archive and the central database without conversion and without losing a bit; export a failure case as a file and attach it to a ticket, or load a test run into the plant database. The format is specified and frozen, and a reference reader on Python's standard library reads it without MorletDB. From Python: morletdb.open("line3.morlet"); also a command line and a C library. The embedded edition is experimental; benchmarks and power-loss tests follow before we publish numbers. Read the post.

Claims you can rerun.

A database earns trust with evidence, not adjectives. Everything below is in the repository, so you can check it yourself instead of taking our word for it.

MorletDB is alpha software: there is no supported production release or security SLA yet (security policy). Long-term operation and power loss are not yet tested.

Ask the index the right question.

Shifted inner-product probes adapt a standard vector index to bounded-lag waveform retrieval. Candidates are re-ranked with the original scorer.

Measured on 234,622 seismic windows and 100 queries, on one machine with warm caches. Recall measures agreement with the exact scorer, not diagnostic relevance. The sparse grid reached 99.9% recall with exact candidates; ANN search reduced it to 97.7%. Probe structures added approximately 1.0–1.3× the compressed raw-data storage across the two evaluated datasets. Other signal domains remain untested for this retrieval method in the report; study N1 has since tested appliance identification from current. These are the report’s numbers (PostgreSQL 17, held-out set). Since SQL 0.3.3, screened exact search is 3.2–3.7× faster (E7, above).

• Report 1 · Recordings, Not RowsLag-tolerant waveform retrieval in PostgreSQL. Version 0.25, released; not peer reviewed.PDF ↗ Supplement ↗ Summary
• Report 2 · Machines with a MemoryEpisodic recall and graded, auditable forgetting for industrial waveforms. Draft 0.2; position and design report.PDF ↗ Summary
• Report 3 · Keeping the Spikes at the EdgeWavelet approximation of machine waveforms at a tenth of lossless size. Draft 0.3; research, not part of a release.PDF ↗ Summary

An archive that lasts, and remembers.

The vision at the top of this page, in more detail: what has shipped toward it, and what comes next.

A recording archive is not a log that only grows. Over years it has to stay fast to search, affordable to keep, and able to answer the question engineers actually ask at the machine: have we seen this before, and what was it? Two lines of thought guide the design.

The argument is set out in report 2, Machines with a Memory (draft) ↗; F1 results in forgetting_f1 ↗.

An open research project.

Built for investigating signal archives. Condition monitoring motivated the work. The report’s retrieval evaluation is seismic; study N1 added appliance identification from current transients, where search matched a current-feature baseline but did not flag unknown appliances. MorletDB is named in honor of Jean Morlet and the project’s initial wavelet hypothesis. Its representations are replaceable, and the current envelope search does not depend on a Morlet transform.