How does pricing work for an existing team workload?

Per resource: vCPU-hour, RAM-GB-hour, storage-GB-hour, traffic GB. The TCO calculator does the math against your current bill — most teams see 30–60% drop versus DIY 5-vendor stacks. Annual contracts available on Cloud Scale.

Is RedDB Cloud SOC 2?

SOC 2 Type II is in progress with a target of 2026 Q3. The engine source is available under BSL 1.1 — your security team can read every line. DPA available on request, BYOK is roadmap on Cloud Scale.

What does a migration from Postgres + pgvector look like?

You point your existing Postgres clients at our wire endpoint — no driver swap. Vector data backfills via `red migrate vectors` while the new collection populates in the background, so the cutover is non-blocking.

Can we host RedDB on our own infra?

Yes. The same binary that powers RedDB Cloud runs on your own VMs / Kubernetes / metal under BSL 1.1. The .rdb file format is identical, so you can move workloads between Cloud and self-host without an export/import dance.

What happens to my data if RedDB the company disappears?

Cloud writes the same .rdb file format as self-host and pushes continuous backups to a bucket you own. Worst case you keep running the self-hosted build with no migration. We're explicit about this because trust shouldn't depend on us being around.

Do you offer enterprise support and SLAs?

Cloud Scale ships a 99.9% SLA, dedicated Slack/Teams channel, and named engineering point-of-contact. Annual contracts and procurement-friendly terms (DPA, MSA) available — email founders@reddb.io.

For engineering teams

One database. One bill. Zero glue code.

If your team is already operating four or more datastores in production, the seams are showing — sync drift, pipelines breaking, oncall burnout. RedDB collapses the surface area into a single engine without giving up any of the data shapes.

Talk to founders — 30 min

Or run the TCO calculator · or spin up a free Cloud workspace

BSL 1.1 self-host
SOC 2 in progress (2026 Q3)
DPA available
BYOK on Cloud Scale

A typical fragmented stack

Most teams find 30–60% of their data infra spend goes to operating the seams. RedDB makes the seams a feature of the engine.

5 managed datastores to operate
3 sync pipelines you wrote yourself
2 vector stores running on hope
1 custom retrieval pipeline drifting from prod

The math

Five vendors, three sync jobs, one oncall — replaced by one engine.

The "right tool for each job" stack made sense when each vendor solved a clearly different problem. With ASK, vector and graph all native to a Postgres-wire engine, the right tool for the job is one tool.

Today

Postgres: rows + indexes
Mongo: docs
Pinecone: vectors + sync
Neo4j: graphs
Influx: metrics + retention
Redis: cache + queues
RabbitMQ: message bus

With RedDB

RedDB: 9 models, 1 engine
Drivers: Rust · JS · Python · Postgres-wire
ASK: cross-model RAG built in

Compare

DIY stack vs Supabase vs RedDB.

Same workload, different surface area. Pick how many products you want to operate to answer one question.

DIY stack vs Supabase vs RedDB
Capability	DIY stack (Postgres + pgvector + Redis + Pinecone + Neo4j)	Supabase (Postgres + extensions)	RedDB Cloud (one engine, 7 models)
Relational tables	yes	yes	yes
Vector search	pgvector + Pinecone	pgvector	native
Graph traversal	Neo4j	no	native
Time-series + retention	Influx	no	native
Queues / consumer groups	RabbitMQ	no	native
Natural-language ASK / RAG	glue code	glue code	one keyword
Domain types (IP, GeoPoint, Money, …)	app code	app code	48 built-in
Services to operate	5+	1	1
Embedded mode (single binary)	no	no	~30MB
Self-host option	yes	yes	yes (BSL 1.1)
Vendor lock-in	low	medium	low

Vendor lock-in: RedDB Cloud exports backups to your S3. Same file format as self-host.

TCO

We already did the math.

Plug your current vCPU, RAM, storage, traffic and per-vendor markups in. Get an apples-to-apples projection against RedDB Cloud.

−42%: infra spend vs DIY 5-vendor stack
−65%: oncall surface area (services to monitor)
3–5x: faster context queries vs application-side stitching

Median results so far. Numbers are based on the first wave of design partners. Your shape will differ — the calculator works it out.

Run the calculator

Migration

Bring your existing data with you.

RedDB speaks the Postgres wire protocol, so existing clients keep working without driver changes. The CLI handles the rest — documents, vectors, graphs.

From Postgres + pgvector

Wire-compatible. Existing clients (psql, pgx, JDBC, Prisma) connect with no changes. Vector data backfills via the same `WITH AUTO EMBED` pipeline.

Shell

# Connect with the Postgres URL — no driver swap.
$ psql "postgres://reddb:secret@db.reddb.io:5432/prod"

# Bring vectors over with auto-embed.
red migrate vectors --from "postgres://..." --collection notes

From Mongo

Documents migrate per collection. RedDB keeps the JSON shape and adds a real query surface (joins, filters, search) on top.

Shell

# Stream collections, preserving _id and indexes.
red migrate documents \
  --from "mongodb://..." \
  --collection logs \
  --collection events

From Pinecone (or any vector store)

Index, embeddings and metadata move to a RedDB vector collection. ASK picks them up immediately without an external retrieval pipeline.
Shell
```
red migrate vectors \
  --from-pinecone "$PINECONE_API_KEY" \
  --index documents \
  --to notes
```
From Custom / N legacy stores

Talk to us — design partners get migration support directly from the engine team.
Shell
```
# Open a conversation:
$ mailto:founders@reddb.io?subject=Migration%20discussion
```

The questions buyers actually ask.

Pricing, security, migration, lock-in. If your question isn't here, email founders@reddb.io.

Email founders