Performance Benchmarks

TL;DR: ekoDB is measured on the industry-standard YCSB suite against PostgreSQL, MongoDB, MySQL and Redis, while encrypting and decrypting every record, against engines encrypting nothing. A single Rust binary covers both the durable and cache tiers, plus auth, encryption, search and real-time subscriptions.

Across every head-to-head throughput matchup in this run, ekoDB leads 19 of 20. The single exception is read-only against PostgreSQL (0.9x).

ekoDB v0.70.1 (5af3aca9), run 2026-09-02, 1,000,000 records, 64 threads. Every figure on this page is rendered from the published artifact, not typed in.

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

When to Use ekoDB (and When Not To)

ekoDB excels when you need: write-heavy workloads with durability, read-heavy throughput, sub-millisecond latencies, CPU-efficient deployments, or a unified platform replacing multiple services (document store + KV + FTS + vector search + auth + real-time subs) in a single binary.

Consider alternatives when: you need specialized OLAP with complex window functions and CTEs (ClickHouse, DuckDB).

Quick Decision Guide

Based on YCSB benchmarks: 1M records, 64 threads, Fast storage mode. See Results Summary for numbers.

Your Workload	Best Choice	Why
Write-heavy + durable	ekoDB	Fastest across all competitors with sub-millisecond latency
Read-heavy + durable	ekoDB, with read-only a coin toss	Leads MongoDB and MySQL on every workload, and PostgreSQL on mixed reads. On 100% read-only the two trade the lead run to run — see Results Summary
Non-durable (any mix)	ekoDB	Competitive or leading, while carrying auth/encryption overhead competitors skip
Low-latency (any mode)	ekoDB	Consistent sub-millisecond across all workloads
CPU cost-sensitive	ekoDB	Better efficiency across durable and non-durable modes
Unified platform	ekoDB	Single binary replaces 4–5 services (auth, search, cache, DB)

---

Why ekoDB's Performance Is Remarkable

ekoDB isn't just fast. It's fast despite doing more work per request than competitors. Understanding this context makes the benchmark results more meaningful.

The Overhead ekoDB Carries

Every ekoDB request includes capabilities that competitors skip entirely:

Layer	What Happens	Competitors
Security	JWT/API key auth, AES-GCM encryption on all stored data	Redis: none, PG: separate
Data	Schema validation, automatic indexing	PG: yes, Redis: none
Search	Full-text + vector search index updates	Requires Elasticsearch + Pinecone
Durability	Configurable persistence guarantees per operation	PG: batched, Redis: async
Real-time	Subscription notifications	Requires additional services

Durability Configuration

ekoDB supports two durability modes via the durable_operations config setting:

Mode	Setting	Behavior	Use Case
Durable (default)	durable_operations: true	Every confirmed write persisted to disk before response	Most workloads, guaranteed persistence
Non-Durable	durable_operations: false	Writes persisted asynchronously	High-throughput, eventual durability acceptable

Durability: The Hidden Performance Tax

Most benchmarks don't match durability settings, making some databases appear faster than they are in production. A database that skips durability guarantees will always benchmark faster — but that speed comes at the cost of data loss on crash. All ekoDB benchmarks use equivalent durability settings across databases for a fair comparison.

---

YCSB Results Summary

Industry-standard YCSB benchmarks: 1M records, 1M operations, 64 threads, Fast storage mode. The run, its version and its commit are stated above and rendered from the artifact rather than written here, so this paragraph cannot drift from the tables under it. Reproduce with make bench-ycsb-compare.

Each engine is compared in the mode it is actually run in. Forcing a cache into per-operation fsync, or a system of record out of it, produces a number nobody can act on.

Run conditions

Throughput only means something alongside what each engine was actually doing per operation, and how it was configured. Both tables below are rendered from the run's own recorded conditions, not from a description of them — a benchmark page is exactly where a setting should never be restated by hand.

Engine	Durability setting recorded for this run
ekoDB	durable_operations=true, group_commits=true, group_commit_delay_ms=2
MongoDB	w=1, journal=true, journalCommitInterval=2ms
PostgreSQL	synchronous_commit=on, fsync=on, commit_delay=2000µs, commit_siblings=2
MySQL	innodb_flush_log_at_trx_commit=1, sync_binlog=1, binlog_group_commit_sync_delay=2000µs
ekoDB (Key-Value)	kv_durable_operations=true, group_commits=true, group_commit_delay_ms=2
Redis	appendonly=yes, appendfsync=always

Engine	Encryption at rest recorded for this run
ekoDB	encrypt_ids=true, encrypt_manifests=true, encrypt_wal=true
MongoDB	none
PostgreSQL	none
MySQL	none
ekoDB (Key-Value)	encrypt_ids=true, encrypt_manifests=true, encrypt_wal=true
Redis	none

This run verified how each compared engine was configured for encryption at rest, so the comparison above is stated rather than assumed.

What each engine offers here is a property of the engine rather than of the run, so it is stated once and linked:

Engine	Encryption at rest available?
ekoDB	Built in. Record-body encryption is unconditional; ids, WAL and manifests are on by default.
PostgreSQL	Not in core — transparent data encryption is not implemented.
MongoDB	Enterprise only.
MySQL	Available in Community via component_keyring_file.
Redis	No built-in at-rest encryption in open source.

Every ekoDB figure on this page is measured while encrypting and decrypting every record. Whether that is a like-for-like comparison depends on what the run verified, which the table above states rather than assumes.

Durable tier: systems of record

Every engine on per-commit fsync with matched group-commit windows. The exact setting each one ran with is in run conditions below, read from the artifact rather than described.

Workload	ekoDB	MongoDB	PostgreSQL	MySQL
Update-heavy 50% reads, 50% updates	31,530	10,849	3,658	2,641
Read-heavy 95% reads, 5% updates	83,913	68,451	33,992	27,166
Read-only 100% reads, point lookups	99,492	74,140	104,427	58,620
Read-latest 95% reads, 5% inserts	84,817	71,362	70,721	45,328
Read-modify-write 50% reads, 50% RMW	35,373	10,060	3,479	3,352

operations per second, higher is better. Best in each row in bold.

Workload	vs MongoDB	vs PostgreSQL	vs MySQL
Update-heavy 50% reads, 50% updates	2.9x	8.6x	11.9x
Read-heavy 95% reads, 5% updates	1.2x	2.4x	3x
Read-only 100% reads, point lookups	1.3x	0.9x	1.6x
Read-latest 95% reads, 5% inserts	1.1x	1.1x	1.8x
Read-modify-write 50% reads, 50% RMW	3.5x	10.1x	10.5x

ekoDB throughput divided by the other engine's. Above 1 means ekoDB is ahead and is shown in bold; below 1 means the other engine is.

Where PostgreSQL leads, it leads on pure point-lookup reads, and that is the one place the encryption trade shows. On write-heavy workloads the fsync dominates and ekoDB's per-record encryption disappears into it; on 1M point-lookups by key there is no fsync to hide behind, so decrypting every record is the whole difference.

The honest statement: ekoDB serves encrypted point reads at close to the throughput of an unencrypted PostgreSQL instance — while also carrying auth, search indexing and subscription dispatch that PostgreSQL is not doing.

Cache tier: in-memory stores

ekoDB's key-value path against Redis. Read the configuration before the ratio: the multiple here moves by an order of magnitude depending on whether Redis is running durable, and the run's actual setting is in run conditions.

Workload	ekoDB (Key-Value)	Redis
Update-heavy 50% reads, 50% updates	38,130	5,966
Read-heavy 95% reads, 5% updates	104,264	6,414
Read-only 100% reads, point lookups	101,895	92,267
Read-latest 95% reads, 5% inserts	89,261	5,950
Read-modify-write 50% reads, 50% RMW	27,359	4,075

operations per second, higher is better. Best in each row in bold.

Workload	vs Redis
Update-heavy 50% reads, 50% updates	6.3x
Read-heavy 95% reads, 5% updates	16.2x
Read-only 100% reads, point lookups	1.1x
Read-latest 95% reads, 5% inserts	15x
Read-modify-write 50% reads, 50% RMW	6.7x

ekoDB throughput divided by the other engine's. Above 1 means ekoDB is ahead and is shown in bold; below 1 means the other engine is.

Why this number differs from the one on ekodb.io

Both surfaces read the same artifact, so when they show different multiples against Redis it is because a run configured Redis differently, not because one of them is wrong. Redis with appendonly=no is how it is normally deployed and is a fair cache-tier comparison; Redis with appendfsync=always answers a different question — what durability costs Redis — and produces a far larger multiple. The table above states which one this run used.

Tail latency and CPU

Throughput is one axis and not the one a deployment is usually sized on. These are the same cells measured the other two ways, with the best value in each row in bold, whichever engine holds it. Each tier is shown separately, because a durable p99 and a cache p99 are not comparable figures and a table that followed the cache section without saying so would read as though they were.

Durable tier — documents, JSON, and rows

Workload	ekoDB	MongoDB	PostgreSQL	MySQL
Update-heavy 50% reads, 50% updates	0.90ms	6.48ms	5.56ms	5.97ms
Read-heavy 95% reads, 5% updates	3.07ms	2.95ms	0.59ms	1.35ms
Read-only 100% reads, point lookups	2.59ms	4.85ms	1.19ms	5.95ms
Read-latest 95% reads, 5% inserts	3.28ms	2.62ms	0.94ms	7.85ms
Read-modify-write 50% reads, 50% RMW	1.12ms	6.50ms	6.01ms	5.36ms

p99 latency, lower is better. Best in each row in bold.

Workload	ekoDB	MongoDB	PostgreSQL	MySQL
Update-heavy 50% reads, 50% updates	145%	172%	70%	54%
Read-heavy 95% reads, 5% updates	187%	468%	159%	200%
Read-only 100% reads, point lookups	171%	476%	328%	316%
Read-latest 95% reads, 5% inserts	178%	460%	295%	318%
Read-modify-write 50% reads, 50% RMW	222%	151%	82%	74%

mean CPU, 100% is one saturated core, lower is better. Best in each row in bold.

Cache tier — key-value

Workload	ekoDB (Key-Value)	Redis
Update-heavy 50% reads, 50% updates	0.96ms	21.62ms
Read-heavy 95% reads, 5% updates	1.32ms	22.28ms
Read-only 100% reads, point lookups	1.52ms	1.09ms
Read-latest 95% reads, 5% inserts	6.73ms	20.68ms
Read-modify-write 50% reads, 50% RMW	5.46ms	21.73ms

p99 latency, lower is better. Best in each row in bold.

Workload	ekoDB (Key-Value)	Redis
Update-heavy 50% reads, 50% updates	134%	25%
Read-heavy 95% reads, 5% updates	290%	24%
Read-only 100% reads, point lookups	200%	76%
Read-latest 95% reads, 5% inserts	221%	23%
Read-modify-write 50% reads, 50% RMW	175%	25%

mean CPU, 100% is one saturated core, lower is better. Best in each row in bold.

What you are comparing against

The tables read as engine against engine, which understates the difference. A production PostgreSQL reaching the same capability is PostgreSQL plus an encryption layer, an auth layer, a cache, a search index, and the code joining them. Each is a component someone writes, deploys, patches, monitors and is paged about.

ekoDB is one binary, with encryption beneath all of it rather than bolted alongside. The measured throughput above already includes that overhead; a competitor number that excludes it is not measuring the same system, only the same benchmark.

Analysis: Why ekoDB Leads

The 1M record, 64-thread YCSB results reveal three architectural advantages:

1. Write Performance Under Durability

ekoDB maintains fast writes even with full persistence guarantees. Where competitors see throughput collapse when durability is enabled (Redis drops to single-digit K ops/sec), ekoDB's write path is designed for durable workloads from the ground up — not bolted on as an afterthought.

2. Scalable Concurrency

At 64 threads, ekoDB scales efficiently with minimal lock contention. Both the Key-Value and Collections engines distribute write load across cores, maintaining consistent performance as thread count increases.

3. CPU Efficiency

Why CPU Efficiency Matters

On cloud platforms, you pay for CPU cores. A database that delivers 50K ops/sec using 200% CPU (2 cores) is more cost-effective than one delivering 60K ops/sec using 600% CPU (6 cores).

Efficiency = ops/sec ÷ CPU%: Higher is better. Lower CPU per operation means smaller instances, lower cloud costs, and more headroom for co-located services.

The Bottom Line

ekoDB achieves these results while carrying significantly more overhead per request than every competitor — auth, encryption, indexing, and real-time subscriptions on every operation. A ~50MB Rust binary with zero garbage collection pauses.

---

Detailed YCSB Benchmarks by Storage Mode

These are earlier runs, kept deliberately

The current figures are the derived ones above. Everything in this section is hand-recorded from earlier comparison runs and is not regenerated from the published artifact, so it will not move when a new run lands.

It is kept rather than deleted because it covers configurations the current artifact does not measure — fast mode non-durable, and balanced mode — and those are real measurements that exist nowhere else. Each block names the run it came from. Where a configuration appears both here and above, the derived version above is the current one.

Industry-standard YCSB (Yahoo! Cloud Serving Benchmark) results comparing ekoDB against PostgreSQL, MongoDB, MySQL, Redis, and ekoDB (Key-Value) with matching durability settings.

YCSB Workloads Explained

Workload	Mix	Real-World Example
A	50% read, 50% update	Session stores, shopping carts
B	95% read, 5% update	Social media profiles, photo tagging
C	100% read	Product catalogs, configuration lookups
D	95% read, 5% insert	News feeds, activity streams
F	50% read-modify-write	Bank transactions, inventory counters

Test Configuration

• Hardware: Apple M1 Max, 64GB RAM, NVMe SSD
• Scale: 1,000,000 records | 1,000,000 operations | 64 threads
• Batch Size: 1 operation per request (raw network performance test)
• Databases: 6 databases tested — ekoDB (Collections), ekoDB (Key-Value), PostgreSQL 15, MongoDB 6.0, MySQL 8.0, Redis 7.x

All databases tested on the same machine, same day, for accurate comparison per configuration.

Driver Asymmetry

PostgreSQL benchmarks use optimized JDBC drivers with connection pooling, prepared statement caching, and batch optimizations built into the driver layer. These are production-grade drivers tuned over decades.

ekoDB benchmarks use raw TCP protocol with a basic YCSB client: no driver-level optimizations, no connection pooling magic, no prepared statement cache.

ekoDB carries this disadvantage into every figure on the page. The current record is counted from the artifact at the top of this page rather than restated here, so the two cannot disagree. The exception is read-only workload C, covered in Results Summary.

---

Fast Mode (Recommended)

Note: All benchmarks include AES-GCM encryption on all stored data.

Fast + Durable

Source run

Everything from here to the end of this section is from the 2026-02-16 comparison run, which put Redis in appendfsync=always. That configuration is kept because it answers a specific question — what Redis costs you when you demand durability from it — but it is not how Redis is normally deployed, so it is not the basis for the headline comparison at the top of this page, which is rendered from the current published artifact and names its own run.

Storage Mode: Fast | Durability: Durable (guaranteed persistence)

Durability Settings

Database	Durable Setting	fsync Behavior	Group Commit Delay
ekoDB	durable_operations=true	WAL fsync, group_commits=true	2ms (explicit)
PostgreSQL	synchronous_commit=on, fsync=on	Per-commit WAL fsync	commit_delay=2000us, commit_siblings=2
MongoDB	w=1, journal=true	WiredTiger journal fsync	journalCommitInterval=2
MySQL	innodb_flush_log_at_trx_commit=1, sync_binlog=1	Per-commit redo log + binlog fsync	binlog_group_commit_sync_delay=2000us
Redis	appendfsync=always	Per-operation AOF fsync	N/A (no group commit)

This is the recommended production configuration. Every confirmed write is persisted to disk before the client receives a response — no data loss on crash, power failure, or unexpected shutdown. In real-world terms: a session store handling 39K mixed read/update operations per second, a product catalog serving 124K lookups per second, or a financial ledger processing 38K atomic read-modify-write transactions per second — all with full durability, encryption, and auth on every operation.

Throughput (ops/sec)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	39,369	112,854	116,442	127,389	37,929
ekoDB (Collections)	36,964	115,128	123,655	118,315	36,937
MongoDB	10,511	72,327	77,095	76,017	10,130
MySQL	2,505	26,730	63,016	45,409	2,324
PostgreSQL	5,420	54,555	107,227	94,949	4,790
Redis	6,022	6,403	103,864	5,999	4,200

Key findings — all figures in this subsection are from the 2026-02-16 run described in the note above, not the derived summary at the top of this page:

• ekoDB leads every workload in that run, both paths scoring A grade (84 and 81 out of 100)
• Workload A (50% read/50% update): ekoDB (Key-Value) 7.3x faster than PostgreSQL, 3.7x faster than MongoDB
• Workload B (95% read/5% update): ekoDB (Collections) 2.1x faster than PostgreSQL, 1.6x faster than MongoDB
• Workload C (100% read): ekoDB (Collections) 15% faster than PostgreSQL (124K vs 107K), 1.6x faster than MongoDB
• Workload D (95% read latest/5% insert): ekoDB (Key-Value) 127K — fastest across all databases and workloads, 1.3x faster than PostgreSQL, 1.7x faster than MongoDB
• Workload F (Read-Modify-Write): ekoDB (Key-Value) 7.9x faster than PostgreSQL, 3.7x faster than MongoDB
• Redis struggles with durable writes (appendfsync=always): 10ms+ latency on non-read workloads, only 4–6K ops/sec on A/D/F

Average Latency (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	0.53	0.46	0.59	0.40	0.43
ekoDB (Collections)	0.43	0.40	0.45	0.39	0.41
MongoDB	1.17	0.44	0.79	0.43	1.38
MySQL	1.54	0.25	0.94	0.58	1.87
PostgreSQL	1.01	0.17	0.56	0.31	1.16
Redis	10.60	9.96	0.61	10.12	10.10

Key findings:

• ekoDB maintains sub-millisecond latencies across all workloads (0.39–0.59ms)
• Lowest latency on write-heavy Workloads A (0.43ms) and F (0.41ms)
• PostgreSQL has lower latency on read-heavy workloads B (0.17ms) and C (0.56ms)
• Redis latency explodes on write-heavy workloads: 10.60ms on Workload A vs ekoDB's 0.43ms — a 24x difference due to per-operation AOF fsync

Tail Latency — P95 (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB	0.75	1.38	1.72	1.64	1.37
MongoDB	6.16	1.97	2.77	1.86	5.15
PostgreSQL	3.56	0.44	1.06	1.24	3.88

Tail Latency — P99 (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB	1.18	2.50	3.14	3.11	3.46
MongoDB	12.03	3.21	6.69	2.90	9.79
PostgreSQL	6.28	0.84	5.20	7.24	6.89

Key findings (tail latency):

• Write-heavy P99 (A, F): ekoDB's P99 stays under 3.5ms — 5–10x lower than MongoDB (9.8–12ms) and 2–5x lower than PostgreSQL (6.3–6.9ms). This means fewer SLA breaches under production load
• Read-heavy P99 (B, C, D): ekoDB delivers consistent 2.5–3.1ms P99. PostgreSQL has lower P99 on Workload B (0.84ms) but spikes to 5.2–7.2ms on C and D
• Predictable tail behavior: ekoDB's P95-to-P99 spread is tight (typically 1.5–2x), indicating consistent performance without long-tail spikes. MongoDB's spread can reach 2–3x on write-heavy workloads

CPU Efficiency (ops/sec per CPU %)

Note: ekoDB intentionally caps CPU usage at 95% to leave headroom for system stability. Other databases typically try to use 100% of available CPU during benchmarks.

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	248	499	548	479	226
ekoDB (Collections)	145	357	447	412	109
MongoDB	46	103	111	116	50
MySQL	46	150	198	155	38
PostgreSQL	45	172	238	222	40
Redis	257	280	1,336	271	175

Key findings:

• ekoDB (Key-Value) achieves 2–5x better CPU efficiency than PostgreSQL and MongoDB across all workloads
• Best efficiency on Workload D: ekoDB (Key-Value) 479 ops/CPU% (2.2x PostgreSQL, 4.1x MongoDB)
• Redis achieves high CPU efficiency on Workload C (1,336 ops/CPU%) due to minimal CPU usage on pure reads, but collapses on write-heavy workloads

CPU Utilization Details

Database	A Avg	A Peak	B Avg	B Peak	C Avg	C Peak	D Avg	D Peak	F Avg	F Peak
ekoDB (Key-Value)	158.4	289.8	226.1	312.5	212.1	305.0	265.4	356.1	167.8	229.5
ekoDB (Collections)	254.8	346.6	322.0	431.4	276.4	383.1	287.1	371.0	337.3	430.4
MongoDB	224.0	344.4	697.2	819.8	690.7	780.6	651.3	763.7	201.8	552.1
MySQL	53.3	85.8	177.4	253.9	317.6	366.2	292.3	365.6	61.1	96.3
PostgreSQL	120.2	182.9	316.3	527.6	450.4	657.0	426.7	630.8	118.8	173.3
Redis	23.4	27.9	22.8	26.8	77.7	94.1	22.1	27.0	23.9	27.8

Measured on 10-core Apple M1 Max. CPU% > 100 indicates multi-core usage.

Fast + Non-Durable

Storage Mode: Fast | Durability: Non-Durable (async persistence)

Durability Settings

Database	Durability Setting	Guarantee
ekoDB	durable_operations=false	Writes persisted asynchronously
PostgreSQL	synchronous_commit=off, fsync=off	No persistence guarantee
MongoDB	w=0	No write acknowledgment

Non-durable mode disables persistence guarantees across all databases for a fair throughput ceiling comparison. This configuration suits ephemeral workloads — session caches, rate limiters, real-time analytics counters, and development environments where maximum throughput matters more than surviving a crash. Even in this mode, ekoDB still performs JWT auth, AES-GCM encryption, and full search indexing on every operation — overhead that PostgreSQL and MongoDB skip entirely.

Throughput (ops/sec)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	87,827	117,536	121,788	118,203	66,124
MongoDB	88,472	79,517	81,024	81,380	60,449
PostgreSQL	80,425	98,561	103,670	105,943	57,707

Key findings:

• Workload A (50% read/50% update): Three-way race — MongoDB (88K), ekoDB (88K), PostgreSQL (80K). ekoDB and MongoDB essentially tied on session stores and shopping carts, with ekoDB carrying auth/encryption overhead that MongoDB skips
• Workloads B–D (read-heavy): ekoDB leads clearly at 118–122K ops/sec, 12–20% ahead of PostgreSQL (99–106K) and 45–50% ahead of MongoDB (79–81K). These are the most common production patterns — social media profiles, product catalogs, news feeds
• Workload F (Read-Modify-Write): ekoDB leads (66K) over MongoDB (60K) and PostgreSQL (58K) — important for financial transactions, inventory counters, and any atomic read-then-update pattern

Average Latency (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	0.56	0.47	0.46	0.47	0.51
PostgreSQL	0.54	0.54	0.58	0.54	0.60
MongoDB	1.39	0.79	0.74	0.78	1.02

Key findings:

• ekoDB and PostgreSQL deliver near-identical sub-millisecond latencies (0.46–0.56ms vs 0.54–0.60ms) — ekoDB edges ahead on read-heavy workloads (B/C/D), PostgreSQL marginally leads on Workload A
• MongoDB trails with significantly higher latencies on write-heavy workloads (1.02–1.39ms on A and F)
• The latency gap matters most for user-facing applications: at p50, both ekoDB and PostgreSQL deliver responses in under 600µs regardless of workload mix

CPU Efficiency (ops/sec per CPU %)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	174	319	348	339	131
PostgreSQL	146	204	206	209	116
MongoDB	122	104	111	110	75

• ekoDB leads CPU efficiency across all workloads — 1.1–1.7x better than PostgreSQL, 1.4–3.1x better than MongoDB
• On cloud platforms, this efficiency advantage directly translates to lower compute costs: ekoDB delivers more throughput per CPU core than competitors while also handling auth, encryption, and search indexing

CPU Utilization Details

Database	A Avg	A Peak	B Avg	B Peak	C Avg	C Peak	D Avg	D Peak	F Avg	F Peak
ekoDB (Collections)	502.5	587.8	368.3	428.2	349.3	397.4	348.1	411.5	504.2	564.2
MongoDB	719.5	876.9	762.9	818.2	728.2	825.6	738.4	835.4	802.9	875.1
PostgreSQL	548.2	683.9	482.3	667.1	502.7	707.7	505.2	717.8	496.2	683.6

Measured on 10-core Apple M1 Max. CPU% > 100 indicates multi-core usage.

Durability vs Performance Trade-off

Non-durable mode is faster but risky:

• Data loss window: Uncommitted writes lost on crash (typically 0–1 seconds)
• Use case: Caches, temp data, dev/test environments, bulk ingestion

Durable mode (default) is recommended for production:

• In durable mode, ekoDB leads write-heavy and mixed YCSB workloads with equivalent durability settings, and trades pure read-only with PostgreSQL
• Use durable for production, non-durable only for caches/temp data

---

Cache Mode: ekoDB KV vs Redis

A head-to-head comparison of ekoDB's Key-Value engine against Redis in pure cache mode — no persistence, no durability overhead. This isolates raw in-memory throughput performance.

Test Configuration

• Hardware: Apple M1 Max, 64GB RAM, NVMe SSD
• Scale: 1,000,000 records | 1,000,000 operations | 64 threads
• Storage Mode: Fast | Durability: Non-Durable (no fsync, no persistence)
• ekoDB: durable_operations=false (async WAL)
• Redis: appendonly=no (no persistence)

Throughput (ops/sec)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	87,078	90,498	90,058	80,782	61,660
Redis	91,701	87,627	88,582	84,182	58,851

Average Latency (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	0.70	0.69	0.72	0.77	0.67
Redis	0.69	0.72	0.71	0.71	0.72

CPU Efficiency (ops/sec per CPU %)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Key-Value)	419	550	588	432	305
Redis	1,189	1,139	1,141	1,087	766

Performance Scores

Database	Score	Grade
Redis	97	A+
ekoDB (Key-Value)	83	A

What This Means

ekoDB matches Redis on throughput (~82K avg ops/sec) and latency (~0.72ms avg) — despite carrying the full overhead described above on every operation. Redis wins decisively on CPU efficiency due to its single-threaded, minimal-overhead design.

If you're choosing between Redis and ekoDB for caching, ekoDB delivers equivalent speed plus built-in auth, encryption, search, and real-time subscriptions — without additional services.

---

Balanced Mode

Source run

From the 2026-02-16 comparison run. Balanced mode is not measured by the current published artifact, so these figures are not regenerated and describe that run only.

Balanced storage mode is designed for datasets larger than available RAM, automatically managing which records stay in memory and which are stored on disk.

Balanced + Durable

Storage Mode: Balanced | Durability: Durable (guaranteed persistence)

Balanced mode is designed for datasets that exceed available RAM — user profile stores, content management systems, and product catalogs where the total dataset is large but the active working set fits in memory. ekoDB leads on write-heavy and mixed workloads (A, B, F) with 1.6–2.9x better CPU efficiency than the three durable engines, while PostgreSQL edges ahead on pure-read workloads (C, D) where its mature query optimizer is most effective.

Throughput (ops/sec)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	30,462	75,267	87,222	81,011	31,818
PostgreSQL	5,207	53,112	103,370	94,769	5,020
MongoDB	11,071	68,714	71,003	68,611	10,423
MySQL	4,603	42,806	61,005	46,155	4,804

Average Latency (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	0.60	0.64	0.67	0.58	0.58
PostgreSQL	1.06	0.17	0.59	0.34	1.17
MongoDB	1.17	0.49	0.87	0.51	1.17
MySQL	1.26	0.30	0.99	0.66	1.20

CPU Efficiency (ops/sec per CPU %)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	108	281	346	342	104
PostgreSQL	43	176	179	199	42
MongoDB	49	96	103	94	43
MySQL	61	144	196	143	60

vs Fast + Durable: Balanced mode trails across all workloads — Fast + Durable delivers 39K (A), 115K (B), 124K (C), 127K (D), 38K (F). The gap is most pronounced on read-heavy workloads where Fast mode's in-memory primary storage eliminates disk access entirely.

Balanced + Non-Durable

Storage Mode: Balanced | Durability: Non-Durable (async persistence)

Non-durable Balanced mode targets development, staging, and batch-processing workloads where datasets exceed RAM and crash recovery is not critical. Without persistence overhead, all databases compete closer to their throughput ceilings.

Throughput (ops/sec)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	51,760	51,560	59,354	80,626	42,746
PostgreSQL	52,059	73,665	85,690	93,318	55,894
MongoDB	82,563	75,483	77,036	75,982	51,634
MySQL	29,932	54,145	59,837	49,044	25,319

Average Latency (ms)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	1.14	1.18	1.02	0.73	1.11
PostgreSQL	0.93	0.81	0.72	0.63	0.67
MongoDB	1.49	0.85	0.79	0.85	1.21
MySQL	1.20	0.94	0.99	1.05	1.29

CPU Efficiency (ops/sec per CPU %)

Database	Workload A	Workload B	Workload C	Workload D	Workload F
ekoDB (Collections)	141	199	245	329	119
PostgreSQL	131	178	154	168	123
MongoDB	122	100	105	99	71
MySQL	84	149	195	153	69

Note: In Balanced + Non-Durable mode, PostgreSQL leads on read-heavy workloads (C, D, F) and MongoDB leads on Workload A. ekoDB maintains a CPU efficiency advantage across most workloads. For maximum non-durable throughput, use Fast mode (66–122K ops/sec vs Balanced 43–81K).

Storage Mode Guide

Mode	Optimized For	Best For
Fast	Maximum throughput, in-memory performance	Low-latency reads, data fits in RAM
Balanced	Memory-efficient, larger-than-RAM datasets	Datasets larger than RAM, general-purpose

---

Feature Comparison

Beyond raw performance, ekoDB consolidates capabilities that typically require multiple external services into a single ~50MB binary. The table below shows what ships built-in versus what requires extensions or separate infrastructure.

Feature	ekoDB	PostgreSQL	MongoDB	MySQL	Redis
Document Queries	✅ Built-in JSON	✅ SQL + JSONB	✅ Built-in BSON	⚠️ JSON columns	⚠️ RedisJSON module
Vector Search	✅ Built-in	⚠️ pgvector ext	⚠️ Atlas only	❌ Needs Pinecone	⚠️ RediSearch module
Full-Text Search	✅ Built-in	⚠️ FTS config	⚠️ Atlas Search	⚠️ FULLTEXT index	⚠️ RediSearch module
Built-in Auth	✅ JWT + API keys	⚠️ Roles only	⚠️ SCRAM only	⚠️ Roles only	⚠️ ACL only
Per-op Encryption	✅ AES-GCM	⚠️ pgcrypto ext	⚠️ CSFLE client-side	⚠️ TDE / app-level	❌ TLS in-transit only
Single Binary	✅ Yes	❌ Multi-process	❌ mongod + mongos	❌ Multi-process	✅ Yes
Real-time Subscriptions	✅ WebSocket	⚠️ LISTEN/NOTIFY	⚠️ Change Streams	❌ Needs external	⚠️ Pub/Sub
Durable Writes	✅ Per-operation	✅ Per-commit	✅ Journal	✅ Per-commit	⚠️ AOF fsync

---

Embedded Benchmarks (Local Performance)

These benchmarks measure ekoDB's core Rust database engine running in-process — no network round-trips, no serialization, no TCP overhead. This represents the performance floor for applications that embed ekoDB directly as a library rather than connecting over the network, and provides a direct comparison against established embedded databases like SQLite, RocksDB, and LevelDB.

Benchmark Environment

All benchmarks run on the embedded Rust database engine. Production performance via REST/WebSocket/TCP APIs includes additional network latency.

Summary

Category	Operation	ekoDB	SQLite	RocksDB	LevelDB
Key-Value	Get	185 ns	~5 µs	~3 µs	~4 µs
Key-Value	Set	3.5 µs	~50 µs	~6 µs	~8 µs
Query	find_by_id	2.3 µs	~10 µs	N/A	N/A
Query	Simple (10 records)	108 µs	~200 µs	N/A	N/A
Insert	Single record	101 µs	~50 µs	~6 µs	~8 µs
Update	Single record	27 µs	~50 µs	~6 µs	~8 µs

When to use ekoDB: Excellent reads and KV operations, plus document queries that RocksDB/LevelDB can't do. The KV layer delivers 185 ns Get and 3.5 µs Set with high-concurrency access.

When to consider alternatives: RocksDB/LevelDB are faster at raw writes. They're pure KV stores without document parsing or indexing overhead.

Key-Value Operations

Operation	ekoDB	SQLite	RocksDB	LevelDB
Get	185 ns	~5 µs	~3 µs	~4 µs
Set	3.5 µs	~50 µs	~6 µs	~8 µs
Exists	109 ns	~5 µs	~3 µs	~4 µs
Delete	85 ns	~50 µs	~6 µs	~8 µs

ekoDB's KV layer uses lock-free concurrent storage optimized for reads. RocksDB/LevelDB edge ahead on writes due to LSM-tree architecture.

Query Operations

Records	ekoDB (Simple)	ekoDB (Complex)	SQLite	DuckDB
10	108 µs	109 µs	~200 µs	~300 µs
100	113 µs	1.16 ms	~500 µs	~600 µs
1000	120 µs	12.8 ms	~2 ms	~15 ms

ekoDB maintains consistent performance as result sets grow. For complex analytical queries, DuckDB is purpose-built for that use case.

Cache Warming

ekoDB's pattern-based cache warming pre-loads frequently accessed records:

Records	Uncached	Cached	Speedup
10	329 µs	109 µs	3.0x
100	3.38 ms	1.08 ms	3.1x
1000	41.4 ms	11.4 ms	3.6x

Write Operations

Operation	ekoDB	SQLite	RocksDB	LevelDB
Single insert	101 µs	~50 µs	~6 µs	~8 µs
Batch insert 100	5.2 ms	~5 ms	~600 µs	~800 µs
Single update	27 µs	~50 µs	~6 µs	~8 µs
Single delete	72 µs	~50 µs	~6 µs	~8 µs

RocksDB/LevelDB dominate write performance. Their LSM-tree design converts random writes to sequential I/O. ekoDB includes indexing overhead that slows writes but accelerates reads and enables queries.

Join Operations

Join Type	ekoDB (10)	ekoDB (100)	ekoDB (1000)	SQLite (1000)
Simple Join	22 µs	528 µs	42.9 ms	~80 ms
Multi-Collection	22 µs	530 µs	40.9 ms	~100 ms
Filtered Join	25 µs	617 µs	45.6 ms	~90 ms

ekoDB outperforms SQLite on joins due to in-memory processing. For complex join strategies on large datasets, SQLite's query planner offers more sophistication.

Authentication & Encryption

Operation	Time
Validate API key	87 ns
Generate token	1.08 µs
Validate token	1.61 µs
Encrypt (small)	2.0 µs
Encrypt (large)	72.3 µs

Sub-microsecond auth overhead means authentication is negligible in request latency.

Feature Comparison (Embedded)

Feature	ekoDB	SQLite	RocksDB	LevelDB
Document queries	✅	✅	❌	❌
Full-text search	✅	✅ (FTS5)	❌	❌
Vector search	✅	❌	❌	❌
Built-in auth	✅	❌	❌	❌
ACID transactions	✅	✅	✅	❌

ekoDB trades some raw write performance for a richer feature set. If you need pure KV speed, RocksDB wins. If you need queries, search, and auth in one package, ekoDB is the only embedded option.

---

See Also

• Query Patterns & Cache Warming - Intelligent caching for 3x faster queries
• Transactions Architecture - ACID transaction performance
• Error Codes - API error reference