For a long time, the default architectural advice was "pick one database and use it for everything." That advice was correct in an era when relational databases were the only mature option and operating two databases was twice the work. Both conditions have changed. Polyglot persistence — using multiple database technologies in a single system, chosen by workload — is a real option for teams that take it seriously.
The pattern is not "use every cool database you've heard of." It is the deliberate choice to put each kind of data on the storage technology that makes it cheapest to work with, when the savings justify the operational cost.
The Workloads That Push You Toward Polyglot
A typical SaaS application has several distinct data access patterns:
- Transactional records — orders, payments, users. ACID, low cardinality of queries, foreign keys. Relational databases are still the right answer.
- High-cardinality search — full-text on products, fuzzy match on names. Inverted indexes and analyzers. Elasticsearch, OpenSearch, or Meilisearch.
- Time-series — metrics, telemetry, IoT. Compression by time, downsampling. TimescaleDB, InfluxDB, or Prometheus.
- Graph relationships — recommendations, social connections, fraud rings. Traversals that hit hundreds of edges. Neo4j or a graph plugin on a relational store.
- Document storage — flexible-schema records, JSON blobs from external systems. MongoDB, DynamoDB, or PostgreSQL's JSONB.
- Cache and ephemeral state — sessions, rate limit counters, computed views. Redis or Memcached.
- Object storage — files, exports, backups. S3 and equivalents.
A small application can serve all of these from a single relational database and a Redis instance. As the application grows, the cost of forcing the wrong workload onto a relational store shows up: storage cost, query latency, and operational pain.
A Realistic Polyglot Stack
A mid-sized SaaS in production might look like this:
| Workload | Storage | Why |
|---|---|---|
| Users, accounts, billing | PostgreSQL | ACID, relational, low write volume |
| Product catalog search | OpenSearch | Multi-field search with relevance scoring |
| Activity feed | Redis Streams | Time-ordered, recent-window dominant access |
| Real-time analytics | ClickHouse | Aggregation over billions of rows |
| File attachments | S3 | Cheap, durable, immutable blobs |
| Audit log | PostgreSQL → S3 (cold) | Hot data queryable, cold data archived |
| Session state | Redis | Sub-millisecond reads, TTL native |
Each store has a job. The boundaries are designed, not accidental.
Keeping the Data in Sync
The hardest problem with polyglot persistence is consistency between stores. Most applications need data to appear in multiple stores — a new product in PostgreSQL needs to be searchable in OpenSearch within seconds.
Three patterns dominate:
Write to one store, project to others via events. The relational store is the source of truth. Writes fire domain events; listeners update the other stores asynchronously.
DB::transaction(function () use ($product) {
$product->save();
event(new ProductSaved($product->id));
});
class IndexProductInSearch
{
public function handle(ProductSaved $event): void
{
$product = Product::with('category', 'attributes')->find($event->id);
$this->searchClient->index($this->toSearchDoc($product));
}
}
Change data capture (CDC). A tool like Debezium tails the database write-ahead log and emits events for every row change. Other stores consume those events. The application code does not know there is a second store.
Dual writes inside the application. Write to both stores in the request handler. This is the simplest pattern and the most failure-prone — partial failures leave the stores inconsistent. Avoid unless the data is non-critical.
The first two patterns are eventually consistent. Design the UI to tolerate it. After a write, the source of truth (PostgreSQL) has the new data; the search index will catch up in seconds.
When the Cost Bites
Polyglot persistence is expensive in three places:
Operational. Every store needs backups, monitoring, capacity planning, security review, and on-call runbooks. Two stores is more than twice the work of one — your team has to be fluent in both.
Cognitive. Engineers have to know which store holds which data and which is the source of truth. New hires take longer to ramp up. Cross-store queries — answering "show me products that have had recent inventory issues" — require either denormalization or join-in-application code.
Consistency. Eventual consistency surfaces in product features. "I just edited my profile, why is the old version showing in search?" is a polyglot-persistence question.
If you have a 3-person team and a single product, polyglot persistence is almost certainly net negative. The operational tax dwarfs the workload-fit savings. If you have a 30-person team and three product surfaces — admin, customer portal, analytics — the savings can be substantial.
Decision Heuristics
Before adding a new store, ask:
- What problem is the single store unable to solve? Write it down concretely. "Search latency is 2 seconds" is concrete. "MongoDB seems trendy" is not.
- Can the existing store solve it with reasonable effort? PostgreSQL has full-text search, JSONB, time-series extensions, and a competent graph mode. Adding a new store has a higher cost than learning a new feature of the existing one.
- Who will operate it? If the answer is "we'll figure it out," the answer is "do not add it." Operating a new datastore is a multi-quarter commitment.
- What is the migration path off this store? Every store is a long-term commitment. The migration path tells you how reversible the decision is.
Common Anti-Patterns
- Cargo cult polyglot. Adding MongoDB because the FAANG blog post used MongoDB. Workloads are not transferable.
- Single-store rejection. "PostgreSQL is just a relational database" — it is also a JSON store, a search engine for many use cases, a time-series store with TimescaleDB, and a queue with
LISTEN/NOTIFY. Master what you have before reaching for new things. - Two-master sync. Two stores both accepting writes for the same data, kept in sync by best effort. This will produce inconsistency. Pick one source of truth.
- Cross-store transactions. Trying to make a write to PostgreSQL and a write to MongoDB atomic. There is no good way to do this. Design the workflow around eventual consistency or pick a different boundary.
Polyglot persistence is a powerful pattern when you have outgrown what a single store can do. It is also one of the easiest patterns to apply prematurely. The path most teams should take: start with one store, push it as far as it will go, and add a second only when the savings clearly justify the operational cost.
Sizing up whether your application needs a second database or just better use of the one you have? We help teams pick the right number of stores — usually one fewer than they were planning. scopeforged.com
