ekoDB is live. Start building for free
Why ekoDB / Performance
Performance that speaks for itself
A Rust engine that holds sub-millisecond latency under load, measured against PostgreSQL, MongoDB, MySQL and Redis on the industry-standard YCSB suite. Every number on this page is read from the benchmark artifact we publish, including the workloads we do not win. Check any of it against the raw run.
Benchmarks
Measured against the systems you already run
In industry-standard YCSB benchmarking, ekoDB won 19 of 20 head-to-head throughput matchups against MongoDB, PostgreSQL, MySQL and Redis, by as much as 16.2x. The single exception in this run is read-only against PostgreSQL (0.9x). Throughout, ekoDB is encrypting record bodies, ids, manifests and the WAL at rest, and decrypting on every read, while the compared engines were verified running without encryption at rest.
Mean operations per second, higher is better, taken over the workloads every engine in the group reported — so the bars are averaged over the same set rather than each engine over whichever workloads it happens to have. The ekoDB numbers carry auth, encryption and search indexing on every operation that the compared engines do not.
Read these as engine throughput, not as what your application will see. Each engine is driven over its own native protocol, and ekoDB's is its internal cluster transport rather than the HTTPS, WebSocket, and SSE endpoints you would connect on. The comparison engines are measured on the protocols their users actually use, so this is favourable to us on that axis.
Documents, JSON, and rows
Durable mode, every database with matching fsync settings.
Key-value
Cache mode, pure throughput, while ekoDB carries AES-256-GCM encryption and search indexing that Redis does not provide out of the box. ekoDB pays for that with cores. Redis saturates a single core by design, so measured per unit of CPU Redis does more work: ekoDB lands at 0.4x–1.5x of Redis throughput per CPU percent while moving more operations per second overall.
Every workload, every engine
The averages above are a summary. This is the run itself — each YCSB workload against each engine, so you can find the mix that looks like your traffic instead of taking an average on trust. The fastest engine in each row is highlighted, whoever it is.
The record above counts throughput, and throughput is not the only axis a database is chosen on. The p99 latency and CPU tabs hold the same rows measured the other two ways — so whatever they say about us, you find it here rather than in your own load test. Deliberately not summarised into a claim: a sentence characterising the tail would be one this page could not re-derive when the next run lands.
Documents, JSON, and rows
Durable mode, every database with matching fsync settings.
| Workload | ekoDB | MongoDB | PostgreSQL | MySQL |
|---|---|---|---|---|
| Update-heavy50% reads, 50% updates | 31,531 (fastest in this row) | 10,850 | 3,659 | 2,641 |
| Read-heavy95% reads, 5% updates | 83,914 (fastest in this row) | 68,451 | 33,993 | 27,167 |
| Read-only100% reads, point lookups | 99,493 | 74,140 | 104,428 (fastest in this row) | 58,620 |
| Read-latest95% reads, 5% inserts | 84,818 (fastest in this row) | 71,362 | 70,721 | 45,329 |
| Read-modify-write50% reads, 50% RMW | 35,373 (fastest in this row) | 10,061 | 3,479 | 3,353 |
ops/sec, higher is better
Key-value
Cache mode, ekoDB carrying encryption and search indexing throughout.
| Workload | ekoDB KV | Redis |
|---|---|---|
| Update-heavy50% reads, 50% updates | 38,130 (fastest in this row) | 5,966 |
| Read-heavy95% reads, 5% updates | 104,264 (fastest in this row) | 6,414 |
| Read-only100% reads, point lookups | 101,895 (fastest in this row) | 92,268 |
| Read-latest95% reads, 5% inserts | 89,262 (fastest in this row) | 5,951 |
| Read-modify-write50% reads, 50% RMW | 27,359 (fastest in this row) | 4,075 |
ops/sec, higher is better
Methodology
How these numbers are produced
Document engines are compared in durable mode with matching fsync settings, and key-value in cache mode. Running one engine durable against another buffered is the easiest way to produce a flattering chart, so the run does not do it.
ekoDB is measured with auth, per-operation encryption, and search indexing switched on. The engines it is compared against do not carry those costs in their numbers, so the comparison is unfavourable to us by construction and we publish it that way.
These runs are driven over ekoDB's internal cluster transport rather than the HTTPS, WebSocket, and SSE endpoints an application connects on. Those carry protocol and TLS overhead the harness does not, so treat these as engine throughput rather than as end-to-end numbers for your own client. The same suite run over the customer transports will be published here from the same artifact, and is not measured yet — so this page does not claim a figure for it.
Nothing here is typed in by hand. Every figure, including the ones where a competitor wins, is derived from the artifact at render time, and a section whose numbers the artifact cannot support renders nothing rather than a stale stand-in. The artifact itself is published below — every number on this page can be checked against it.
Run 0.70.1, 1M records, 64 threads. ekoDB figures include auth, per-operation encryption, and search overhead on every request.
Disclosed with this run:
- ekoDB encrypts at rest; the competitors in this run do not. Read-side results are encrypted-vs-plaintext, not like-for-like
The published artifact this page reads from can be found here. For the full write-up, see the performance reference in the docs.
Go deeper
Explore more about ekoDB
Try ekoDB free
Deploy your first database in minutes. No credit card required.