Executive Summary
- Pick stores by responsibility ownership, not by familiarity or fashion.
- One durable writer of truth per business fact prevents split-brain.
- Redis is typically cache, session, rate-limit, or coordination—not default durable SoR.
- MongoDB documents still have schema-in-practice; plan migrations and validation.
- Polyglot persistence is justified by workload evidence and ops capacity—not by collecting databases.
- Conventional single-store architectures remain appropriate for many products.
Ownership decision
Polyglot persistence fails when teams pick stores by blog popularity. The real decision is which component owns each responsibility: transactional truth, document aggregates, search projections, cache, rate limits, sessions, and job coordination.
PostgreSQL, MongoDB, and Redis can coexist usefully only with an ownership matrix and dual-write rules. Without that, you get three partial truths and no reliable audit story.
Technology detail pages cover stack depth; this guide owns cross-store responsibility boundaries. Fit depends on workload and operational requirements—validated in discovery.
One writer of truth per fact
If two stores can independently update the same business fact, you do not have a boundary—you have a future incident.
Responsibility map
PostgreSQL commonly owns relational integrity, multi-row transactions, and durable financial or entitlement facts. It is often the system of record for core business entities.
MongoDB may own flexible document aggregates, rapidly evolving content shapes, or workloads where document locality helps—provided you define validation, indexes, and migration discipline. It is not 'schema-free'; applications always assume shape.
Redis commonly owns hot cache, sessions, rate limiting, locks, and short-lived coordination. Treating Redis as the durable source of record for money or entitlements is a common design error unless a deliberate persistence and recovery model is engineered and operated.
Default responsibility hypotheses (validate per workload)
| Responsibility | Often PostgreSQL | Often MongoDB | Often Redis |
|---|---|---|---|
| Durable SoR for money/entitlements | Yes | Sometimes with care | No (default) |
| Multi-entity transactions | Yes | Limited patterns | No |
| Document aggregates / content | Possible | Yes | No |
| Hot read cache | Possible | Possible | Yes |
| Session / rate limit / lock | Possible | Rare | Yes |
| Search | Extensions / external | Atlas Search / external | No as primary search |
Transactions, consistency, derived data
Transactions should live where the durable writer of truth lives. Cross-store transactions are usually avoided; prefer outbox patterns, idempotent consumers, and explicit reconciliation.
Derived data (search indexes, read models, analytics) must be marked as projections. Rebuild procedures are part of the architecture, not an afterthought.
Queues and streams are adjacent concerns: use purpose-built brokers when durability and consumer groups matter; do not overload Redis lists as a permanent job bus without ops justification.
Invalidation, backup, recovery
Cache invalidation needs versioning or TTLs tied to the source of truth. Serving stale entitlements from cache is a security and billing incident.
Backup and recovery must be defined per store. Restoring one store without the others can produce inconsistent customer state—document the order of restore and rebuild of projections.
Operational complexity multiplies with each store: monitoring, capacity, security patches, and on-call. Provider guarantees depend on configuration and operations.
When polyglot is unsuitable
Multiple databases are unsuitable when a single well-modeled store meets integrity and access patterns, when the team cannot operate the fleet, or when dual-writes are proposed without reconciliation.
MongoDB is unsuitable as a dumping ground for relational facts that need strong multi-entity constraints without a clear aggregate design.
Redis is unsuitable as the only home for durable business state you cannot afford to lose or rebuild.
One database is often enough
Conventional architecture with PostgreSQL (or another primary store) plus careful indexing may be sufficient. Add stores when measured pain justifies ops cost.
Failure modes
Cross-store risks dominate: split brain after partial writes, cache serving stale entitlements, and 'temporary' denormalization that never reconciles.
What must remain deterministic: writes to the system of record and entitlement checks. What can be automated: cache warming and projection rebuilds—with verification.
Validate before build: ownership matrix, dual-write rules, backup order, and on-call ownership per store.
Implementation checklist
Do not add a store without a named responsibility and operator.
Store boundary checklist
1Ownership
- SoR named per fact class
- No dual writers without reconciliation
- Projection rebuild documented
2Cache
- Invalidation strategy
- TTL or version keys
- No durable money in cache-only
3Ops
- Backup/restore order
- On-call per store
- Complexity justified by workload
How Digital Elliptical helps
Digital Elliptical helps backend and data teams define store responsibility matrices, projection patterns, and operational ownership—favoring honest boundaries over collecting databases.
We do not guarantee latency targets or cost reductions from polyglot designs. Fit depends on workload evidence and operational maturity.
Main-Agent ownership (Prompt 6): Re-authored to reject Redis-as-SoR defaults, reject 'schema-free' MongoDB myths, and emphasize single-store sufficiency.