Compared Read/write path Engine internals Use cases Deploy targets Requirements Fit check
PRODUCT

What it is, how it works, and what it will not do.

The engine, the read/write path, where it fits - and the honest list of requirements before you commit.

Sound familiar

Every fast-growing team hits the same wall.

Your database was fine at 1M users. Somewhere between 10M and 100M, things got expensive. Then slow. Then both.

Our database bill tripled and we didn't ship a single feature.

More data means more reads. More reads mean bigger Redis clusters or paying DynamoDB per million ops. The bill grows faster than revenue.

— VP Engineering, Series C
Latency is fine at 9 AM, then spikes to 500ms at noon.

Traditional databases run internal cleanup jobs that fight your user requests for disk access. Peak traffic + compaction = your worst nightmare.

— Staff SRE, fintech
We're burning through SSDs every few months.

Databases without key-value separation rewrite your data over and over. Every unnecessary rewrite is wear on expensive NVMe — a tax on your latency.

— Platform Lead, ad-tech
Compared

Why replace what you're running today.

A feature-by-feature look at how VeltrixDB stacks up against the databases teams typically outgrow.

Capability Redis DynamoDB Cassandra ★VeltrixDB
Sub-5ms P99 at 1B keys In-memory only ~12ms typical ~80ms typical 4.9ms · NVMe-backed
Predictable infra cost RAM-bound Pay per million ops Ops overhead Fixed infrastructure
Compaction-free reads No compaction Hidden, but spikes Major spikes Separate I/O path
Cloud portability Self-managed work AWS-only Yes Helm · any cloud
Observability included Roll your own CloudWatch only Roll your own 50+ metrics + Grafana
Time to production Days Minutes Weeks 94 seconds
Architecture

Fast, simple, and it just works.

All the complexity is hidden. You write data. You read data. At any scale. Without weekend on-call incidents.

› Live data path · 1024 shards Read packet Write packet
AppWALVLogIndexCache
Single-key write · 128 B value · TCP binary protocol
PATH 01 / 03 — DURABLE WRITE

Value lands on NVMe before ack.

Group-commit WAL batches concurrent writes into a single fsync. The value goes straight to the VLog via O_DIRECT — the index keeps only a 24-byte pointer. Zero write amplification.

01App → WAL~12µs
02WAL fsync (group-commit)~80µs
03VLog → NVMe O_DIRECT~30µs
04Index pointer update~8µs
05Cache warm → ack~5µs
End-to-end · P99 ~0.2 ms
Under the hood

Not a wrapper. A storage engine, rebuilt.

We didn't put a faster cache in front of a slow database. We re-engineered the storage layer at the kernel boundary — two technical bets explain everything.

Technical whitepaper · 42 pages

Want the full architectural document?

Block-by-block diagrams of the write/read paths, the durability proof behind the 99.999% SLA, the sharding model, the LIRS cache internals, and the chaos-engineering failure matrix — all in one PDF. Written for the engineer who'll be on call for this in production.

9 chapters 18 diagrams v0.9.5 · June 2026
Read the whitepaper ↗ Email me the PDF
01
Storage engine

Key–value separation, WiscKey-style.

Classical LSM trees rewrite every value during compaction — a 10× write amplification tax that destroys NVMe lifetime and detonates tail latency. We split keys from values.

Index shards hold only 24-byte VLog pointers — small, cache-resident, and fast to compact. Values live in an append-only VLog on NVMe and are never rewritten by compaction. Garbage collection runs on a dedicated I/O queue that cannot stall reads.

The benchmark we expose on the performance page shows write amplification of 1.0× sustained — RocksDB and Cassandra typically run at 6×–12×. Multiply that by your NVMe replacement cycle and the cost story writes itself.

Write amp
1.0×
vs 6–12× elsewhere
Index pointer
24 B
per key, cache-resident
GC interference
0
separate I/O queue
Inspired by the WiscKey paper (FAST '16) — production-hardened for sharded multi-cloud deployments.
See the benchmark Cost impact
02
Kernel I/O

io_uring with SQPOLL. Zero syscalls on the hot path.

Traditional databases pay a syscall and context-switch tax on every read. We bypass it entirely — the kernel polls our submission queue, and read latency collapses.

In io_uring SQPOLL mode, a kernel thread polls a shared ring buffer for I/O submissions. Our hot path issues reads with zero syscalls per operation. O_DIRECT sidesteps the page cache for deterministic NVMe latency — no eviction noise, no surprise jitter from another tenant.

Each of our 1024 shards owns a dedicated submission queue. At the kernel boundary it looks less like a database and more like a 1024-way parallel storage controller. The architecture is laid out in our technical whitepaper, and you can see the result live on the cluster dashboard.

Syscalls / read
0
SQPOLL kernel thread
Parallel queues
1024
one per shard
P99 NVMe read
4.9 ms
under sustained writes
Open source under Apache 2.0. Every component is on GitHub and the architecture is documented in full — read the code, or the whitepaper.
Get the whitepaper Live cluster metrics
Where it fits

Built for teams where microseconds move money.

We don't pretend to be a general-purpose database. VeltrixDB is a hyper-specialized point-lookup engine — if you're running one of these workloads at extreme scale, this was built for you.

01 — AdTech & Real-Time Bidding

User profile lookups inside the 50ms RTB budget.

Fetch the user profile, score the bid, write the impression — millions of times per second. Point lookups are the entire workload. Range queries aren't needed. Your RAM budget and bare-metal NVMe match the architecture perfectly.

User profilesBid scoringImpression writesDSP / SSP
02 — HFT & Crypto Exchanges

Lock-free architecture, microsecond determinism.

Order books, position state, and risk checks where every microsecond is a P&L line item. Lock-free shards, dedicated I/O queues, and zero-syscall reads — the architecture was built for trading desks who never accept jitter.

Order booksPositionsRisk stateTick storage
03 — Persistent caches & session stores

Redis-class speed, without RAM-class bills.

When your dataset has outgrown the budget of "keep everything in RAM," but you still need sub-millisecond access. DRAM index over NVMe values gives you 5–10× the working set on the same hardware spend — persistent, durable, no rehydration after restart.

Session storesHot cachesCDN edgeFeature lookups
04 — Fraud detection & rate limiting

Continuous writes, instantaneous lookups.

Stream transactions in, score them against history, decide in single-digit milliseconds. Write amplification of 1.0× means your NVMe survives the write rate; point-lookup speed means your risk engine never has to fall back to "approve and reconcile."

Fraud scoringRate limitsVelocity checksUser history
Global Infrastructure

One binary. Any cloud. Anywhere.

Deploy on GKE, EKS, AKS, or bare metal with a single Helm command. Identical NVMe performance everywhere. No retuning, no specialist hire, no lock-in.

Edge presence

Replicate across 7 continents — without paying egress to do it.

Active-active replication keeps every region within milliseconds of writes — failover is automatic, traffic shifts before your alerting fires. Run on your own VPC, your own NVMe, your own networking.

14
Active regions
99.999%
SLA at edge
GCP
Google Cloud · GKE
n2-highmem-96
Local NVMe SSDs
AWS
Amazon · EKS
i3en / im4gn
Local NVMe
AZURE
Microsoft · AKS
Lsv3 NVMe series
Full StorageClass
SELF-HOST
Bare metal
Direct NVMe · any Linux
No hypervisor overhead
~/veltrixdb · zsh
$ helm repo add veltrixdb https://charts.veltrixdb.com
"veltrixdb" has been added to your repositories
$ helm install veltrixdb veltrixdb/veltrixdb \
    --namespace veltrixdb --create-namespace
✓ StorageClass · veltrixdb-nvme
✓ StatefulSet · 3 replicas, anti-affinity
✓ ServiceMonitor · 50+ metrics
✓ PodDisruptionBudget · minAvailable 2
✓ Ready in 94s
$
⎈ Kubernetes-native
StatefulSet · anti-affinity · PDB
⚓ Helm chart
one command · full values.yaml
🤖 K8s operator
auto-scale · reshard · self-heal
📊 Prometheus + Grafana
50+ metrics · alerts · dashboards
Honest fit check

What it won't do — and what it needs.

We'd rather lose the deal than oversell. VeltrixDB is a scalpel, not a Swiss Army knife — here's the truth about hardware, query patterns, and memory before we get on a call.

Hard requirements we won't bend on.

Last updated · May 2026
⚠
Bare-metal NVMe or local SSD only
Optimised strictly for direct-attached NVMe with Linux io_uring. Not recommended for AWS EBS, Azure managed disks, or any network-attached storage — they break the latency model.
⚠
Point lookups only
Purpose-built for high-throughput GET / SET / DEL at scale. Range queries, secondary indexes, joins, and full-text search are not supported natively — wrong workload for VeltrixDB.
⚠
RAM budget for the ART index
The adaptive radix index lives in DRAM. Plan ~12 GB RAM per 100M keys (varies with key size). 1B keys on a node needs ~120 GB RAM. You will not run this on a t3.medium.
Linux kernel ≥ 5.10 required for io_uring SQPOLL · AVX2 CPU baseline · 3-node minimum for production durability Talk to an architect before you commit →
60-SECOND FIT CHECK

Five questions. An honest verdict.

The same qualification we run on every demo call — answered here so you don't need the call to find out we're the wrong tool.

0 / 5 answered
01Dominant access pattern?
02Working-set size?
03Strictest latency SLA?
04Write durability model?
05Must survive a full zone outage with zero data loss?

Ran the fit check? Pressure-test us on your workload.

Book an architecture review ↗ See the measured numbers
30 minutes with an engineer, not a salesperson · We will tell you if we are the wrong tool