When you don't need RedDB

We sell a database. Telling you when not to buy it is, on the face of it, a strange use of a marketing surface. We do it anyway because the alternative — watching someone migrate onto RedDB, hit a wall that was visible from a mile away, and churn six months later — is a worse outcome for everyone. A reader who saves a migration they would have regretted is a reader who trusts the next post.

This piece is the list. If your shape is here, the right answer is “stay where you are” or “pick the boring single-purpose store.” We will be specific about which one.

The frame: what RedDB is actually for

RedDB earns its keep when a single workload needs more than one storage shape at the same time. Relational rows with vector search next to them. Documents with full-text search next to them. Event log with derived materialized views next to it. The pitch is that the second shape is in the same transaction, the same auth model, the same backup, the same operator surface. If you do not have two shapes — or you have two but they never need to be consistent with each other — most of that value evaporates and you are paying the cost of a less-mature engine for no return.

Everything below is a variant of “you only have one shape, or your two shapes never need to be consistent.”

1. Single-modality OLTP with no vectors and no documents

If your data model is “ten well-normalized tables, some foreign keys, a handful of indexes, and the hardest query is a three-way join,” use Postgres. Not pgvector, not a multi-model anything — just Postgres.

Postgres at this shape is the boring right answer for reasons that have very little to do with the database itself:

Every cloud has a managed Postgres with a 10-year operational track record. The on-call story is solved without you doing anything.
Every ORM, every BI tool, every analyst-facing dashboard speaks Postgres natively. You do not have to argue with anyone about driver support.
Every senior engineer you will ever hire has debugged a Postgres query plan before. Ramp-up is zero.

The RedDB pitch in this shape reduces to “maybe slightly different operational defaults.” That is not enough to justify being the one team in your company on a less-deployed engine. Stay on Postgres.

2. Embedded / single-user / single-process workloads

If your workload runs in a desktop app, a mobile app, a CLI, an edge device, or a serverless function with a local writable disk, use SQLite. (For mobile-first sync, Turso or Cloudflare D1 sit on top of the same engine and add the sync layer.)

SQLite is not “Postgres lite.” It is a fundamentally different operating model — in-process, zero servers, the file is the database. RedDB is a server process with a network protocol; running it embedded would be a category error. The minute your data fits this shape, every “but RedDB has feature X” is irrelevant because the cost of running a server next to your app dwarfs the value of feature X.

Heuristic: if your “production deployment” is “ship a binary that touches a local file,” SQLite is the answer.

3. Workloads where the second shape never needs to be transactionally consistent

This is the subtle one. Just having “two shapes” does not mean you need a multi-model database. The honest question is: do the two shapes need to be consistent with each other on every write?

Take the classic “I want logs and metrics next to my OLTP data.” You almost certainly do not need those to be in the same transaction as your business writes. The log write losing a record because of a transient downstream outage is fine. The metric being a few seconds stale on a dashboard is fine. Stream them into the dedicated tool (Loki, Prometheus, ClickHouse) and let the OLTP database be the OLTP database. The cost of putting them in the same engine is real; the consistency benefit is zero because no consumer of those streams expects strict consistency.

A useful test: if you can imagine an outage where one shape lags the other by 30 seconds and no user ever notices, you do not need transactional consistency between them, and you do not need a multi-model database. You need two databases and an event bus.

The RedDB shape that earns its keep is the inverse — the search index that lags the document by 30 seconds will show a user a result that no longer matches the source. Drift visible to users is the bar.

4. Hyper-low write volume with no operational team

If you are a two-person team running a marketing site, an internal tool, or a side project that does fewer than ~1 write per second on a peak day, the operational overhead of running any dedicated database is larger than the storage problem you are solving.

Concretely: use the database your hosting provider offers in the same control plane as your app. Supabase Postgres, Vercel Postgres, Neon, PlanetScale, Cloud SQL — whichever is one click from where your app already runs. You will not benefit from RedDB’s multi-model story at this volume because you do not have time to build a system that uses the multi-model story. You have time to ship features, and a managed Postgres with zero ops on your plate is what enables that.

A subtler version of this rule: even if you do have two shapes (you want vector search for an AI feature), if you are a two-person team, use Postgres + pgvector until you outgrow it. It is one engine, one backup, one connection pool. The drift-window problem is real but tolerable at low write volume, and you will know when you have outgrown it because users will start complaining about stale search results.

5. Teams without ops appetite for a less-mature engine

This is the most uncomfortable item on the list, so we will be direct: RedDB is younger than Postgres. It has fewer years of production deployments, fewer post-mortems published, fewer Stack Overflow answers for obscure error codes. The engineering is solid, the test coverage is good, the public benchmarks hold up — but maturity is a function of calendar time and number of operators, and there is no shortcut.

If your organization treats database choice as a near-irreversible commitment, if your security team requires three years of public CVE history before approving an engine, if your on-call rotation does not have one engineer who is comfortable reading source code when a tool misbehaves — those are entirely reasonable constraints, and the rational choice under them is the most-deployed engine in your category. Pick Postgres. Pick the cloud-native option from your provider. Revisit RedDB in 18 months when more deployments have shaken out the edges.

We would rather you make that call clear-eyed than have you adopt RedDB, hit an operational surprise, and conclude the engine is unfit when the actual mismatch was risk appetite.

6. Workloads that are really about analytics, not transactions

If the dominant query pattern is “scan large slices of historical data and aggregate,” you have an analytical workload, and the right answer is an analytical engine: ClickHouse, DuckDB, BigQuery, Snowflake, depending on your scale and budget. Putting analytical scans on a transactional engine — any transactional engine, RedDB included — gets you a much worse cost-per-query than the dedicated tool, and you lose the columnar storage and vectorized execution that make analytical engines fast.

The mixed shape (some OLTP, some analytical) is real and is one of the places RedDB is genuinely interesting, but the threshold is “the analytical queries are a minority that need to see fresh transactional data.” If your analytical queries are the majority of your workload and they can tolerate a 5-minute replication lag from a source-of-truth OLTP store, the two-engine answer (Postgres → ClickHouse via CDC) is cheaper and more performant.

7. You already have the four engines and they are working

If you are currently running Postgres + Elasticsearch + Pinecone + Redis and the team is happy, the on-call is quiet, and your latency numbers are within budget — do not migrate. The “small-team unlock” story for RedDB (we wrote a separate post on the ops math) is about teams who would otherwise adopt four engines. The cost of migrating an already-working four-engine stack is almost never recovered by the operational simplification, because the migration itself burns the budget that would have funded the simplification.

The rule of thumb we use internally: a migration earns its budget back if it is paying down a problem the team is currently losing sleep over. If nobody is currently losing sleep, leave the stack alone and spend the engineering time on features.

8. Strict regulatory requirements naming a specific engine

A small number of regulated industries have certifications that name specific database engines, or specific cloud-managed offerings, in the compliance scope. If your auditor’s checklist says “Postgres with FedRAMP-authorized hosting” and RedDB is not on that list, the cost of getting it added to the authorized boundary exceeds the value, period. Use the named engine.

This is not a knock on the engine — it is a recognition that compliance scopes are slow-moving by design, and a database choice is not the right place to spend novelty budget when an auditor is in the loop.

The shapes where RedDB does earn its keep

For balance, here is the inverse list — shapes where the multi-model story actually pays off:

RAG workloads where the embedding must stay consistent with the source document on every write (the drift-window problem). Long-form version of the argument here.
Agent memory layers where episodic events, semantic facts, and procedural caches are written and read together in the same request.
Search-over-mutable-data products where the search index lagging the source by even seconds is a user-visible bug.
Multi-tenant SaaS with per-tenant isolation where running N copies of four engines is cost-prohibitive but per-tenant rows in one engine is tractable.
Small teams (2–5 engineers) who would otherwise stand up four engines — the ops cost math flips here, not at high scale.

If you are not in one of those shapes, the honest answer is the boring one. Save the migration for a problem that needs it.

TL;DR

Stay on what you have if:

One storage shape, no vectors, no documents → Postgres.
Embedded / single-process → SQLite.
Two shapes that never need to be consistent → two databases and an event bus.
Two-person team, tiny write volume → whatever your hosting provider runs.
Risk-averse org with hard maturity requirements → Postgres.
Analytics-dominant workload → ClickHouse / DuckDB / BigQuery.
Four engines that are working and quiet → leave them alone.
Auditor named a specific engine → use the named engine.

We will be here when one of the inverse shapes shows up.