COMPRESSION-NATIVE · DISK-PERSISTENT · VECTOR + GRAPH
Store 8× more on disk. Retrieve at the same fidelity. Pay a fraction.
CRBRL is a compression-native, disk-persistent vector database. Its codec layer is peer-reviewed (arXiv:2504.19874, ICLR 2026) — so the claims below are numbers, not adjectives.
PER VECTOR
AFTER COMPRESSION
VS 6,144 B FLOAT32
ZERO-TRAINING CODEC
Embeddings grew into an economics problem.
One 1,536-dimension embedding stored as float32 is 6,144 bytes. At 100 M vectors that is 614 GB — and RAM-first engines ask you to keep it hot to stay fast.
The industry answer has been bigger clusters. The math answer is fewer bits.
EMBEDDING (E.G. OPENAI)
BEFORE COMPRESSION
HELD AT FULL PRECISION
TurboQuant: 8× fewer bytes, ≈0.98 cosine fidelity, no training step.
TurboQuant is data-oblivious: no codebook, no training pass, no drift as your corpus changes. A random rotation plus Lloyd-Max quantization (PolarQuant), corrected by a 1-bit QJL inner-product estimator, takes a 1,536-dim vector from 6,144 B to 768 B at ≈0.98 cosine recall.
Point cloud is a 2-D projection for illustration. Fidelity figures for the 4-bit operating point are from arXiv:2504.19874; intermediate points interpolated.
Zandieh · Daliri · Hadian · Mirrokni — Google Research + NYU
arXiv:2504.19874 · published at ICLR 2026
Two shipped codecs. Pick per memory class, not per vendor roadmap.
Compression is CRBRL's substrate, not a mode you switch on. The codec layer is selectable — benchmark a corpus against both, assign the better fit to each memory class.
TurboQuant
Data-oblivious. No training, no codebook, no drift. Maximum storage reduction: 8× fewer bytes per vector at ≈0.98 cosine fidelity.
RaBitQ
Randomized bit-quantization with an unbiased distance estimator and a provable error bound — for workloads where accuracy must be guaranteed, not just demonstrated.
Search runs inside the compressed domain. Nothing inflates first.
Most engines compress at rest, then decompress to query — paying the byte cost back at read time. CRBRL's distance estimators operate on the compressed representations themselves, so the 8× saving holds through the entire query path.
Similarity says what's related. The graph says how. One engine answers both.
CRBRL ships vector search and relationship intelligence in the same engine — one query, one store, one operational surface. The prevailing alternative is stitching a vector database to a separate graph database and reconciling two systems of record.
Semantic retrieval
Compressed-domain ANN over HNSW, hybrid lexical + semantic ranking with BM25 + RRF. Built for RAG and agent memory read paths.
Relationship intelligence
Entities and edges live beside the vectors they describe. Traverse how documents, people, and events connect — without exporting to a second database.
Tiering and compression multiply. Others make you choose.
Hot, warm, and cold classes each carry their own codec setting. Cost engineering that tiers full-precision vectors saves on where bytes sit; CRBRL first shrinks the bytes, then tiers them.
Active working set — lowest-latency reads, codec tuned for fidelity.
Recent but not resident — compressed-domain reads straight off disk.
Long-tail memory — maximum-density codec settings, still queryable.
8× compression × tiered placement = compounding, not either/or.
System-level cost outcomes are workload-dependent — the 8× / ≈0.98 codec figures are the peer-reviewed constant; what they compound into depends on your read mix and corpus shape.
Two products. Both shipped, both under one brand.
Everything on this sheet is v0.1.0 capability — no roadmap items listed. Design partners are in flight.
CRBRL · STANDALONE
SINGLE DOCKER IMAGE · .NET 8
| API SURFACE | REST v1/v2 (Chroma-compatible), gRPC, native MCP server |
| RETRIEVAL | HNSW ANN + BM25 lexical + reciprocal-rank fusion |
| CODECS | TurboQuant (default) · RaBitQ — selectable per memory class |
| GRAPH | Entities + edges beside vectors; one query surface |
| EMBEDDINGS | 9 providers supported out of the box |
| OPERATIONS | Multi-tenant RBAC · snapshots · distributed sharding |
| PERSISTENCE | Disk-first; compressed-domain reads off disk |
crbrl-pg · POSTGRES EXTENSION
RUST · PGRX
| WHAT IT IS | TurboQuant vector types + HNSW operator classes inside Postgres |
| MIGRATION | pgvector workloads move without a database swap |
| WHY | Keep transactions, backups, and tooling where they already live |
| FOOTPRINT | 8× fewer bytes per vector inside your existing tables |
| STATUS | Shipped · design partners in flight |
Arrive without a migration project. Leave nothing behind.
CRBRL speaks the interfaces you already use: Chroma-compatible REST for existing clients, a native MCP server for agents, and a Postgres extension for pgvector estates.
$ docker run -p 8000:8000 crbrl/crbrl:0.1.0 # Chroma-compatible REST — existing clients just point here $ curl localhost:8000/api/v2/heartbeat {"nanosecond heartbeat": 1753077600000000000} # agents connect over native MCP — no adapter layer
postgres=# CREATE EXTENSION crbrl; CREATE EXTENSION -- pgvector migration without a database swap: -- TurboQuant types + HNSW opclasses, in-place -- 6,144 B → 768 B per 1,536-dim vector
If your vector bill is a line item you flinch at, send us the shape of it.
Tell us dimensions, corpus size, and read mix — we'll reply with what the codec math says it becomes on CRBRL. Design-partner slots are limited by engineering attention, not sales capacity.