nDB
An LSM-tree storage engine written from scratch in C, zero dependencies. There is a real nDB process running on this server right now with 50,000 rowsloaded. Don't take the numbers on faith — fire the benchmarks below and watch the measured latency yourself.
A live nDB process is serving 50,000 rows on this server. Benchmark headline numbers are measured by nDB's own latency histogram — the database's real speed, not the web round-trip.
Pick a workload and size, hit run. Every request is a real op against the live C engine. The headline numbers are measured by nDB itself (its own latency histogram) — not the browser/Node round-trip.
How fast is this, honestly, vs other databases?
Typical order-of-magnitude figures — all hardware- and workload-dependent. nDB's numbers are measured on a shared 1-core VPS with a small, RAM-resident 50k-row dataset.
| engine | class | point read | point write |
|---|---|---|---|
| nDB (SYNC_NONE) | embedded LSM, C | ~1–16µs cache/memtable | ~1–8µs |
| RocksDB / LevelDB | embedded LSM (its peers) | ~1–10µs cache · ~50–200µs disk | ~1–5µs memtable |
| Redis | in-memory store | sub-µs in-proc · ~0.1–1ms loopback | similar |
| SQLite (sync=OFF) | embedded SQL | ~1–10µs in-cache | ~µs OFF · ~ms FULL |
| Postgres / MySQL | client-server RDBMS | ~0.1–1ms+ local | ~ms durable commit |
Where it's genuinely fast: nDB's engine is in the same microsecond class as RocksDB/LevelDB for cache/memtable-resident data, and ~140k writes/sec on one shared core. For a from-scratch hand-written C LSM engine that is a real result, and structurally it beats any client-server RDBMS on raw point-KV latency (no SQL planner, no MVCC, no network framing beyond a 5-byte header).
The asterisks: it runs SYNC_NONE (no fsync) — apples-to-apples with Redis-without-persistence or SQLite synchronous=OFF, not a durable Postgres commit (turn on SYNC_PER_WRITE and writes drop to single-digit % of this). It is single-node, single-process and feature-light: no transactions/MVCC, limited SQL, no replication, no concurrent-writer scaling, and none of the decade of adversarial-workload hardening RocksDB/Redis/Postgres have. At 100M keys under compaction pressure with concurrent writers, the mature engines pull ahead.
Bottom line: as fast as RocksDB/Redis for small cache-resident KV, faster than any SQL RDBMS at raw point lookups — it wins "impressive µs-per-line-of-C", not "production database". A genuinely fast engine and a strong systems project; not a drop-in replacement for a battle-tested datastore.
Backed by a live nDB instance (durability mode SYNC_NONE — no fsync overhead, highest throughput). Bridge is read-biased and rate-capped; the engine is CPU/RAM-sandboxed. Read the C source →