Performance

KiteDB is designed for speed. This page explains why it's fast and how to get the best performance from it.

Why KiteDB is Fast

1. No Network Overhead

10-1000x speedup just from eliminating network.

2. Zero-Copy Memory Mapping

Hot data stays in RAM automatically. Cold data is paged in on demand.

3. Cache-Friendly Data Layout

4. Lazy MVCC

Benchmark Results

Latest snapshot (single-file raw, Rust core, 10k nodes / 50k edges, edge types=3, edge props=10, syncMode=Normal, groupCommitEnabled=false, February 4, 2026):

Node Ops

Edge Ops

Full logs and run commands are in docs/benchmarks/results/.

Write Durability vs Throughput

• Defaults stay safe: syncMode=Full, groupCommitEnabled=false.
• Single-writer, low latency: syncMode=Normal + groupCommitEnabled=false.
• Multi-writer throughput: syncMode=Normal + groupCommitEnabled=true (1-2ms). Scaling saturates quickly; prefer prep-parallel + single writer for max ingest. See benchmarks notes.
• Highest speed, weakest durability: syncMode=Off (testing/throwaway only).

Group commit adds intentional latency to coalesce commits; it improves throughput under concurrency, but can slow single-threaded benchmarks.

Decision Table

Performance Playbook

• Fastest ingest (single writer): beginBulk() + createNodesBatch() + addEdgesBatch() / addEdgesWithPropsBatch(), syncMode=Normal, groupCommitEnabled=false, WAL ≥ 256MB, auto-checkpoint off during ingest, then checkpoint.
• Multi-writer throughput: syncMode=Normal + groupCommitEnabled=true (1-2ms window), batched ops per transaction.
• Read-heavy, mixed workload: Keep batches small, checkpoint when WAL ≥ 80%, avoid deep traversals.
• Max speed, lowest durability: syncMode=Off for testing only.

Bulk-load mode requires MVCC disabled. Use it for one-shot ingest or ETL jobs.

Bulk Ingest Example (Low-Level)

// Fast ingest: low-level API
db.beginBulk();
const nodeIds = db.createNodesBatch(keys); // keys: string[]
db.addEdgesBatch(edges); // edges: { src, etype, dst }[]
db.addEdgesWithPropsBatch(edgesWithProps);
db.commit();

// Optional: checkpoint after ingest
db.checkpoint();

Best Practices

Batch Writes

// Slow: Individual inserts (1 WAL sync per op)
for (const key of keys) {
  db.createNode(key);
}

// Fast: Batch + bulk-load transaction
db.beginBulk();
db.createNodesBatch(keys);
db.commit();

// 1000 nodes × 1μs + 1 WAL sync = ~2ms

Limit Traversal Depth

// Potentially expensive: deep traversal
const alice = await db.get(user, 'alice');
const all = db
  .from(alice)
  .traverse(follows, { direction: 'out', maxDepth: 10 })
  .nodes()
  .toArray();

// Safer: bounded traversal + limit
const friends = db
  .from(alice)
  .traverse(follows, { direction: 'out', maxDepth: 2 })
  .take(100)
  .nodes()
  .toArray();

Use Keys for Lookups

// Fast: Key lookup (O(1) hash index)
const alice = await db.get(user, 'alice');

// Slower: Property scan (O(n) nodes, done in JS)
const aliceByName = db.all(user).find((u) => u.name === 'Alice');

Design keys to match your access patterns.

Checkpoint Timing

// For write-heavy bursts: Compact snapshots after large ingests
await importLargeDataset();
db.optimize();

// Inspect storage stats
const stats = db.stats();

Memory Usage

Profiling Tips

// Get database statistics
const stats = db.stats();
console.log(stats);
// {
//   snapshotNodes: 100000,
//   snapshotEdges: 500000,
//   deltaNodesCreated: 1200,
//   deltaEdgesAdded: 3400,
//   walBytes: 10485760,
//   recommendCompact: false
// }

// If recommendCompact is true:
// → Run db.checkpoint() or db.optimize()

Next Steps

• CSR Format – Why traversals are fast
• Snapshot + Delta – How reads stay fast during writes
• Benchmarks – Detailed performance measurements