Comparison benchmark / 2026-08-02
Benchmark,
not brochure.
One workload, one host, equal retention and indexing semantics, exact correctness checks, two warmups, and five measured trials per system.
Bulk telemetry ingestion · 80,000-event durable batches
200,800 events
per second.
ArcherDB reached 26.9× the PostgreSQL + PostGIS median and 4.2× the Valkey median through its Python SDK — with every system configured for per-batch durability and driven with the same 80,000-event batches by one client. All three ingestion series passed the predeclared 10% variability gate (worst CV 1.5%). The server itself goes further still — see the native-client ceiling below.
| System | Median events/s | Five-trial range | CV | Batch p99 |
|---|---|---|---|---|
| ArcherDB Lite (Python SDK) | 200,800 | 196,073–204,015 | 1.5% | 3.08 s |
| PostgreSQL 17.5 + PostGIS 3.5.2 | 7,478 | 7,447–7,571 | 0.6% | 11.41 s |
| Valkey 9.1.1 | 47,814 | 47,275–48,809 | 1.2% | 1.96 s |
Server ceiling · native client
902,000events/sArcherDB’s own bulk-load harness (archerdb benchmark), same single node, maximum batch size (81,916 events per request), every write consensus-committed and fsync’d before its reply. This measures the database without a Python client in front of it — the gap to the 200,800 figure above is client-side serialization cost, not the server. It is reported separately because the competitors were not driven by an equivalent native client, so it is not part of the apples-to-apples comparison.
| System · 1,000-event batches | Median events/s | Five-trial range | CV | Batch p99 |
|---|---|---|---|---|
| ArcherDB Lite (Python SDK) | 71,109 | 66,535–73,717 | 4.1% | 47.5 ms |
| PostgreSQL 17.5 + PostGIS 3.5.2 | 8,601 | 7,848–8,618 | 3.9% | 184.7 ms |
| Valkey 9.1.1 | 40,404 | 40,305–41,125 | 1.0% | 35.7 ms |
Coverage: ArcherDB Lite, one node, LAB45. Standard through Ultra and LAB96 were not tested. ArcherDB's latest-record and radius-query series varied by more than 10% across trials, so those results remain diagnostic rather than stable public comparisons.
What we measured
A narrow,
useful question.
On the same single-node hardware, how do the systems compare when each durably retains and geospatially indexes full event history while maintaining a separate latest-position index?
- Dataset
- Bulk profile: 20,000 entities · 2,000,000 events. SDK-default profile: 10,000 entities · 100,000 events
- Client
- One load generator · CPUs 4–7 · 80,000-event batches (bulk) / 1,000-event batches (SDK default) · durable acknowledgement per batch
- Servers
- One at a time · CPUs 0–3 · same LAB45 host
- Trials
- Two warmups excluded · five measured trials retained
- Queries
- 2,000 latest lookups · 500 non-empty 3 km radius queries
- Correctness
- 1,500 latest records + 7,500 radius result sets checked; competitor history and latest counts verified
Comparable intent
Writes that
survive.
The comparison uses durable configurations, full records, and the same retention and indexing contract. No system gets to discard history that another must preserve.
- ArcherDB Lite
- Every event appended to its S2-keyed Forest LSM; latest RAM index maintained; successful single-replica SDK upsert committed before return.
- PostgreSQL + PostGIS
- Every event inserted into GiST-indexed
geo_history;geo_latestmaintained in one transaction;fsync=onandsynchronous_commit=on. - Valkey
- Every event stored in history GEO + metadata; latest GEO + pointer maintained atomically; AOF enabled with
appendfsync=always. - Isolation
- Each measured competitor trial started a fresh process with an empty storage volume; all measured containers had zero OOM events and zero restarts.
Limits
One result.
Defined boundaries.
This is not a universal database ranking. It is a single-node, single-client run on a shared virtual host, using ArcherDB Lite and one dataset, batch size, and durability profile. CPU affinity reduced direct contention, but the machine was not dedicated bare metal. Re-run the suite for other hardware, concurrency, replication, or workloads.