Store 8× more on disk.
Retrieve at the same quality.
Cut the line item.

CRBRL is a vector database built around peer-reviewed compression mathematics. Works with any embedding model, any dimension. No retraining, no calibration.
7–8× more efficient storage Drop-in for Chroma · Augments Postgres Works with all major embedding models
CeReBRaL
— Pronounced cerebral · spelled like the data
crbrl.ai Sydney + global
— Bytes per vector at 1,536 dimensions
6,144 raw float
768 CRBRL
8× smaller · same retrieval quality
— 100M-vector corpus, on disk
614 GB raw float
77 GB compressed
The line item that scales linearly
— Migration effort
Months typical rebuild
5 minutes compatible API
No application rewrite
— Reference workload: 100 million vectors at 1,536 dimensions, the typical OpenAI text-embedding setup. Compression ratio holds across embedding models and dimensions.
— a small clarification
The vowels were never load-bearing.

Same word. ⅛ the bytes. The brand is the product demo, said out loud.

— 01 · The bill

Every vector database stores embeddings as a 32-bit float.

That choice was made when embeddings were 128-dim and corpora held 100,000 records. It hasn't been revisited. A 1,536-dim OpenAI vector is now 6,144 bytes on disk, in WAL replication, in object-storage tiers, and in every byte of the working set the buffer cache has to hold. That's the bill you pay every month. Storage and IO together drive 55–80% of vector-database cost.

The bill, in motion.

A 100-million-vector retrieval corpus at typical embedding dimensions: 614 GB of raw embedding bytes — on disk, on every replica, in every backup, in every snapshot. Across managed services and self-hosted clusters, that footprint scales linearly with both your data and your dimension count. CRBRL stores the same vectors in 77 GB. Same retrieval quality. Migrate in a weekend.

614 GB · 100M × 1,536-dim float32 → 77 GB compressed at 3-bit
14:02:11wal.append · session_42 · +6,144 B/vector · disk+38 MB
14:02:16cloud.bill · this month · running total$14,240
14:02:15wal.fsync · 380 ms · CRC32 ok+38 MB
14:02:14compaction.lag · cell_03 · 12 min behindqueued
14:02:14pinecone.bill · this hour · 100M-vec corpus$8.77
14:02:13cache.miss · 23% · scan fallback
14:02:13s3.replica_b · sync · 614 GB / 100M vec14h ETA
14:02:12rag.compliance · +44,002 docs · embed + index+264 MB
14:02:11pgvector.shard_03 · +112,440 floats · index+1.04 GB
14:02:11wal.append · session_42 · +6,144 B/vector · disk+38 MB
14:02:16cloud.bill · this month · running total$14,240
14:02:15wal.fsync · 380 ms · CRC32 ok+38 MB
14:02:14compaction.lag · cell_03 · 12 min behindqueued
— 02 · The unlock

Compression is the architecture.

100,000,000 vectors · 77.0 GB on disk · 8.0× density
— 03 · Two products. One codec.

Pick the way you already deploy.

CRBRL ships as a standalone vector database for greenfield deployments, and as a Postgres extension for teams already running on Postgres. Same engine, same retrieval quality — different operational shape.

— 01 · Standalone

CRBRL

A vector database for greenfield deployments. Compatible with the Chroma API, so applications already using Chroma migrate without code changes. Same database from development through production scale.

● Live
Drop-in for · Chroma · Pinecone · Weaviate · Qdrant
— 02 · Postgres extension

crbrl-pg

An extension for your existing Postgres database. The crucial difference: search runs directly on the compressed index — no decompression in the query path. That's what makes it efficient at scale, and why bolt-on compression in other engines never matched it.

● Live
Augments Postgres · no migration, same database
— Engine

TurboQuant

Compression mathematics that work on the first vector you load. No training. No calibration. Peer-reviewed and proven near information-theoretic optimal.

● The moat
— Tier migration

Hot · Warm · Cold

Recent data stays at higher fidelity. Older data compresses further as it ages. Automatic, in the background. No operational work.

● Automatic
— Search

3 modes, 1 API

Semantic search, full-text, and hybrid retrieval — all in one query interface. All running directly on compressed data.

● Semantic · text · hybrid
— Embeddings

All major providers

OpenAI, Gemini, Cohere, Mistral, and more — built in. Switch providers without rebuilding your pipeline. Use whichever fits the workload.

● Per-collection configuration
— Enterprise

Production-ready surface

Authentication, audit logs, multi-tenancy, observability, and snapshots. Built in from day one, not bolted on when customers ask.

● Enterprise security on the roadmap
— 04 · Memory tiers

Hot stays hot. Cold pays nothing.

Three tiers, automatically managed. Recent data stays at higher fidelity. Older data compresses further as it ages. No operational work — the system shifts records as their access pattern changes.

Hot
Active · ≤ 24h
Warm
Recent · 24h–30d
Cold
Archive · > 30d
Automatic · runs in the background No drift over time Configurable per workload
— 05 · Why now

The category just hit its inflection.

AI infrastructure is being rebuilt around retrieval. Vector databases are the fastest-growing line item in that rebuild, and storage is the fastest-growing line item inside vector databases. Compression is the lever no incumbent has pulled yet — because their engines weren't designed for it.

$170B
— AI infrastructure, 2029E

From $91B in 2026 at 23% CAGR. The data-substrate layer (vector retrieval, graph, agent memory, cache) goes from $12B to $27B in the same window — 31% CAGR, faster than the broader market. Source: Precedence Research, Jan 2026.

55–80%
— Of a vector-DB bill is storage + IO

Embedding dimensions doubled in 24 months — 768 → 1,536 → 3,072. Corpora grew super-linearly. The bytes scale by both axes; the bills compound monthly. Hot-cache hit rates fall as corpora grow. None of this is a feature.

7–8×
— Compression with no quality loss

Every major vector database stores embeddings as 32-bit floats — the default since the category began. That choice was made when embeddings were 128-dimensional. Peer-reviewed mathematics now compresses the same vectors 7–8× with no retraining and no recall loss. The first lever in the category that doesn't trade quality for cost.

— 06 · Run it on your numbers

What does that cost you?

Move the buttons. The math runs on your inputs against the same compression ratio TurboQuant produces in the codebase. No registration. No "talk to sales." Numbers update live.

384 HuggingFace MiniLM  ·  768 Gemini, Ollama  · 
1,536 OpenAI text-embedding-3-small  ·  3,072 OpenAI -3-large
— Storage on disk
Raw float614 GB
CRBRL compressed77 GB
— What that means
Same retrieval quality. 8× less footprint on disk, in replicas, in every backup. The line item that used to scale linearly with your data — now compounds to your favour.
— The compression ratio holds across embedding models and typical dimensions (384 through 3,072). Storage estimates above reflect the embedding-bytes line item only; index and metadata footprint vary by workload.
— 07 · The numbers, honestly

The numbers, simply.

Standard benchmarks. Same retrieval quality at every compression level — pick the trade-off that fits your workload.

— Compression ratio
Same vectors. ⅛ the bytes on disk. Across every embedding model.
Same
— Retrieval quality
Benchmarked on standard suites. Same accuracy as your current setup — verifiable on your data.
9
— Embedding models supported
OpenAI, Gemini, Cohere, Mistral, and more. Switch without rebuilding your pipeline.
0
— Retraining required
Works on the first vector you load. Drop in any embedding model.
— 08 · Migration

A configuration change, not a project.

If you're on Chroma, point your existing application at CRBRL — the API is compatible. If you're on Postgres, add the extension to the same database. Five minutes to first query, either path.

— A · Chroma migration · Python
Before chroma # your existing stack import chromadb client = chromadb.HttpClient(host="localhost", port=8000) col = client.get_or_create_collection("docs") col.add(documents=docs, ids=ids) col.query(query_texts=[q], n_results=10)
After crbrl · same chromadb client # point at CRBRL — same Chroma API import chromadb client = chromadb.HttpClient(host="crbrl.local", port=5000) # ← migration col = client.get_or_create_collection("docs") col.add(documents=docs, ids=ids) # 8× less on disk col.query(query_texts=[q], n_results=10) # compressed-domain
— B · pgvector augmentation · SQL
Before pgvector -- existing pgvector setup CREATE EXTENSION vector; CREATE TABLE docs (   id bigserial PRIMARY KEY,   embedding vector(1536) ); CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
After pgvector + crbrl-pg · same database -- add CRBRL to your existing Postgres CREATE EXTENSION crbrl; -- ← installs alongside your current vector setup ALTER TABLE docs ADD COLUMN embedding_compressed   crbrl_vector(1536); UPDATE docs SET embedding_compressed = compress(embedding); CREATE INDEX ON docs USING hnsw (embedding_compressed crbrl_cosine_ops); -- same database · 8× smaller index · same retrieval quality
Available in private preview. Get in touch for early access.
— 09 · Who this is for

Built for the workloads that scale by the gigabyte.

— ML platform teams

RAG over compliance, support, and code. Storage-heavy, latency-sensitive.

Compatible API · fast migration
— Postgres-heavy infra

Existing Postgres deployments. Same database, same operations, same backup story.

Postgres extension · no new system
— Cost-driven operators

Vector retrieval that doesn't grow faster than the budget. Storage line drops by an order of magnitude.

Operational economics
— Join our early adoption program
A small group of design partners.

We're working with a handful of teams whose retrieval bills aren't aging well. Tell us a bit about your stack — we'll be in touch.

For early-access, partnership, and investor inquiries