Microsecond Latency: Benchmarking CameoDB's Zero-Copy Architecture

The Zero-Copy Advantage

When you're processing millions of documents, every memory allocation matters. Traditional databases copy data through multiple layers, network buffers, serialization formats, intermediate structures, each adding latency and GC pressure. CameoDB takes a different approach: zero-copy ingestion.

Built with Rust 2024 Edition, CameoDB uses the language's ownership model to pass data by reference without copying. When you stream a CSV from Hugging Face, parse JSON from a local file, or ingest NDJSON over HTTP, the bytes travel through a single buffer. No serde allocations. No intermediate clones. Just raw bytes flowing from source to storage.

Hybrid Storage: Two Engines, One Pipeline

CameoDB's performance comes from its hybrid architecture, combining redb (ACID-compliant KV store) with Tantivy (full-text search engine). Each write operation follows an atomic sequence:

// 1. Generate sequence ID (AtomicU64, lock-free)
seq_id = counter.fetch_add(1)

// 2. Begin redb transaction (ACID isolation)
txn = kv.begin_write()

// 3. Write to WAL (durability before application)
wal.insert(seq_id, serialized_op)

// 4. Write to data table (complete JSON document)
data.insert(id, json_blob)

// 5. Update Tantivy index (in-memory buffer)
writer.add_document(id_only_doc)

// 6. Commit redb transaction (fsync if configured)
txn.commit()

// 7. Signal supervisor for smart commit
supervisor.reset_timer()

The key insight: Tantivy stores only indexed fields. The complete JSON document lives exclusively in redb. When you search, Tantivy returns matching document IDs, then we batch-fetch the full documents from redb. This split-storage strategy means smaller indices, faster searches, and zero data duplication.

Supervised Smart Commits: The 5-Second Guarantee

Committing to disk is expensive. Doing it on every write kills throughput. Skipping it risks data loss. CameoDB's Supervised Smart Commits thread the needle with an adaptive algorithm:

Smart Commits

Trigger when operation count reaches adaptive threshold (500-8000 ops based on memory budget). Immediate commit during write bursts.

Supervised Commits

After 5 seconds of write inactivity, background supervisor commits. Guarantees durability for low-volume patterns.

Every write signals a per-index supervisor, resetting a 5-second timer. If writes stop flowing, the supervisor fires an eventual commit. If writes keep coming, smart commits trigger at adaptive thresholds. Supervisors self-cleanup after successful commits, no resource leaks, no background tasks lingering.

Tiered Cache Sizing: Fast Startup, Steady State

Opening a 2GB database with a 32MB cache is painful. CameoDB uses a two-phase initialization strategy:

// Phase 1: Init Boost (fast WAL recovery)
cache_size = database_tier * multiplier
// Small: 32MB → 32MB (1×)
// Medium: 128MB → 512MB (4×)
// Large: 256MB → 2GB (8×)

// Phase 2: Normal Operation (steady state)
cache_size = standard_tier
// Release init boost memory for multi-shard deployments

For a 2GB database on a node with 16GB RAM, CameoDB opens with 512MB cache for fast recovery, then drops to 256MB for steady operation. Per-shard memory is automatically divided across all active shards, no manual tuning required.

Benchmark Results: The Numbers

So what does this architecture deliver in practice? Here are real-world benchmarks from the storage engine:

Single Operations

0.5-3ms per operation

Depends on fsync configuration

Batch Operations

0.05-0.5ms per operation

10-60x faster than single ops

Point Queries

~0.1ms (redb B-tree)

KV lookup by document ID

Search Queries

10-100ms (Tantivy)

Depends on index size, complexity

Throughput scales dramatically with batching: 2,000-15,000 ops/sec individual versus 10,000-100,000 ops/sec batched. The difference comes from amortized commit overhead and reduced mutex contention.

Async-Sync Isolation: Blocking Without Blocking

All redb and Tantivy I/O happens inside tokio::task::spawn_blocking. This is critical: storage operations are inherently blocking (disk I/O, B-tree traversals, index segment merges). By offloading to a dedicated blocking thread pool, CameoDB's async runtime stays responsive. No thread starvation. No latency spikes from blocking the event loop.

The Takeaway

Zero-copy ingestion, hybrid storage, supervised smart commits, tiered caching, async-sync isolation, these aren't isolated optimizations. They're an integrated architecture where each component amplifies the others. Rust's ownership model makes zero-copy safe. The hybrid split-storage strategy enables smaller indices. Smart commits reduce I/O while supervised commits guarantee durability. The result: sub-millisecond latency at scale, without the complexity of manual tuning.