Recovery benchmark

How long a developer waits between the first call to the enterprise download API and a usable local copy of the anonymized database, per engine and dataset size. The measurements come from one developer machine and show the shape and order of magnitude, not a performance guarantee.

Which engines these numbers cover

Three engines were measured on 2026-09-23: PostgreSQL 15.19, MariaDB 10.11.19 and Redis 7.0.15.

Not measured. MongoDB, Apache Kafka and Redpanda, Microsoft SQL Server, Oracle Database and CouchDB have no figures here, and none are estimated from the three that do: their developer download and restore workflows have not been timed by this benchmark harness, so there is no comparable first API call measurement here. Valkey is not measured either — the Redis row is redis-server 7.0.15; no recovery benchmark was run against Valkey. MySQL and Percona Server are not measured separately from MariaDB, and the MariaDB figures are a logical dump, not the physical path. An engine’s absence here means only that: not measured. It is not a claim in either direction about how fast it would be.

What was measured

rows / keys: the number of rows or keys in the dataset. artifact: the size of the published artifact. All timing columns are in milliseconds. prepare and publish are the operator’s side, outside the developer total.

For each size (10,000 / 100,000 / 1,000,000 rows or keys), the harness:

1. prepare -- seeds the rows on the primary under a hash rule and waits until the anonymized replica holds every one (the replication side; not part of the developer's wait).
2. publish -- takes a fresh base and publishes it to the artifact catalog (backup-base + backup-publish, or backup-publish alone for Redis). This is the operator's schedule, reported separately.
3. api -- GET /databases/default/latest with a database-scoped token.
4. download -- GET .../artifacts/{id}/download, one request.
5. verify -- SHA-256 of the bytes against the manifest.
6. restore -- unpack and restore with the artifact's own restore.sh (PostgreSQL: a new instance on a spare port; MariaDB: an import into a fresh database; Redis: a redis-server booted on the .rdb, counted as usable only once it has finished LOADING) until every row is present.

developer total = api + download + verify + restore. Every harness asserts the restored copy carries no plaintext before reporting.

Results (milliseconds)

PostgreSQL 15.19 -- the artifact is a physical base of the replica server plus its WAL, which is why 10,000 rows already weigh 102 MB:

MariaDB 10.11.19 -- the artifact is a logical .sql.gz; the import is the cost that grows with size:

Redis 7.0.15 -- an RDB snapshot over the replication protocol:

Caveats

• Localhost transfers: download times measure the API server, not a network. On a real link the download column scales with artifact size and bandwidth; the other columns do not change.
• The rows are narrow (an id, an e-mail, a 40-byte note). Wide rows and indexes grow the artifact and the restore.
• One run per cell, on a machine that was also running a mutation gate. Repeat before quoting a number to anyone.
• Three engines, three sizes, one artifact format each. Do not extrapolate from these rows to another engine, another artifact format or another machine — see which engines these numbers cover.