Performance

This page explains where KiteDB's read and write latency comes from, shows measured results, and covers the settings that trade durability for throughput.

What keeps latency low

1. No network round trip

The p50 figures come from the benchmark run described under benchmark results.

2. Memory-mapped snapshot

Hot data stays in RAM and cold data is paged in on demand. Checkpoints compress snapshot sections with zstd by default; a compressed section is decompressed once and cached in memory, so only uncompressed sections are read in place.

3. Cache-friendly data layout

4. Lazy MVCC

Benchmark results

Single-file raw benchmark on the Rust core (10k nodes, 50k edges, 3 edge types, 10 edge props, 1k vectors of 128 dims, sync=normal, MVCC on), Apple M5 Pro, October 3, 2026. Each row is the median of five interleaved runs.

Node operations

Edge operations

Raw log: docs/benchmarks/results/2026-10-03-r2-single-file-raw-rust-mvcc-normal.txt. The benchmarks pages have the other runs and their commands.

MVCC cost

Throughput with MVCC on against MVCC off on the same machine, from mvcc_overhead_bench (sync off, so a commit costs CPU rather than an fsync wait; each case is the median of five runs):

Source: 2026-10-03-r2-mvcc-overhead.txt (modes=off,on nodes=20000 edges/node=8 props/node=4 duration=1s repeat=5 history=2000x8 sync=Off cpus=15)

Writer threads need MVCC: without it, write transactions run one at a time. With syncMode=Normal, one writer without MVCC reaches 5.0K/s with transactions of 200 nodes and 200 edges, and eight MVCC writers reach 12.7K/s (2.5x).

Write durability vs. throughput

• Defaults: syncMode=Full: a commit returns once it is fsynced; commits that arrive together share the fsync.
• Single writer, low latency: syncMode=Normal.
• Several writer threads: syncMode=Normal (or Full, whose fsyncs the commits share). With MVCC (the default), writers build their transactions in parallel, and commits that arrive together are written as one group. For one-shot ingest, a bulk load through one writer is still fastest. See the parallel write scaling notes.
• Fastest, least durable: syncMode=Off, for tests and throwaway data only.

Every commit is group-committed: the commits that arrive while a group is written form the next group, written with one WAL write, one header write and, in Full mode, one fsync, then published in order (each commit whole). No commit waits for others to join, so a single writer pays nothing for it. This works in every sync mode, with MVCC and on a replication primary; groupCommitEnabled and groupCommitWindowMs have no effect.

Decision table

Performance playbook

• Fastest ingest (single writer): beginBulk() + createNodesBatch() + addEdgesBatch() / addEdgesWithPropsBatch(), syncMode=Normal, and the default checkpoint settings: a full WAL spills into WAL segments and checkpoints run on the checkpoint thread, so the WAL needs no resizing (a larger one means fewer spills, but raises the floors of the checkpoint trigger, the segment limit and the segment extent). With auto-checkpoint off, writes fail once the WAL segments reach walSegmentLimit or fill the segment table (63 extents; with default extents about four times a limit up to 512 MiB, and 2 GiB beyond): raise the limit, and walSegmentSize with it past that, to hold the whole load, then checkpoint.
• Several writer threads: syncMode=Normal, several operations per transaction, and a retry for commits that fail with a conflict.
• Read-heavy, mixed workload: keep write batches small, leave auto-checkpoint on (it runs once the log reaches half the snapshot's size, at least 3/8 of the WAL, at most 128 MiB; tune with checkpointLogRatio and checkpointLogBudget), and bound traversal depth.
• Fastest, least durable: syncMode=Off, for testing only.

A bulk load of 200k nodes and 1M edges with 2 properties each, in batches of 5,000, ran at 2.88M/s for nodes and 1.00M/s for edges with MVCC, and 2.90M/s and 975K/s without it (Apple M5 Pro, examples/bulk_load_bench.rs). It runs alone among writers, and readers never wait for it. A read transaction held open across the load slows its edge inserts (615K/s in the same test, with nodes at 2.95M/s), because the load's commits record version history for it. Use it for one-shot ingest or ETL jobs.

Bulk ingest example (low-level API)

1// Bulk ingest with the low-level API2db.beginBulk();3const nodeIds = db.createNodesBatch(keys); // keys: string[]4db.addEdgesBatch(edges); // edges: { src, etype, dst }[]5db.addEdgesWithPropsBatch(edgesWithProps);6db.commit();78// Optional: checkpoint after ingest9db.checkpoint();

Best practices

Batch writes

1// Slow: one transaction (and one WAL sync) per node2for (const key of keys) {3  db.begin();4  db.createNode(key);5  db.commit();6}78// Fast: one bulk-load transaction for the whole batch9db.beginBulk();10db.createNodesBatch(keys);11db.commit();1213// Rust core benchmark: 100 nodes per batch, 17.92 µs p50 (syncMode=Normal)

Limit traversal depth

1// Potentially expensive: deep traversal2const alice = db.get(user, 'alice');3const all = db4  .from(alice)5  .traverse(follows, { direction: 'out', maxDepth: 10 })6  .nodes()7  .toArray();89// Safer: bounded traversal + limit10const friends = db11  .from(alice)12  .traverse(follows, { direction: 'out', maxDepth: 2 })13  .take(100)14  .nodes()15  .toArray();

Use keys for lookups

1// Fast: key lookup (O(1) hash index)2const alice = db.get(user, 'alice');34// Slower: property scan (O(n) nodes, done in JS)5const aliceByName = db.all(user).find((u) => u.name === 'Alice');67// Design keys to match your access patterns.

Checkpoint timing

1// After a large ingest, fold the delta into a fresh snapshot2await importLargeDataset();3db.checkpoint();45// Inspect storage stats6const stats = db.stats();

Memory usage

Profiling tips

1// Get database statistics2const stats = db.stats();3console.log(stats);4// {5//   snapshotNodes: 100000,6//   snapshotEdges: 500000,7//   deltaNodesCreated: 1200,8//   deltaEdgesAdded: 3400,9//   walBytes: 10485760,10//   recommendCompact: false11// }1213// If recommendCompact is true, run db.checkpoint()

Next steps

• CSR format: how adjacency is laid out for traversal
• Snapshot and delta: how reads stay consistent during writes
• Benchmarks: full measurements and run commands