Odoo runs on PostgreSQL. At some point on most engagements, someone proposes adding a second store next to it: Redis for caching, Elasticsearch for search, a document database for a feature that feels document-shaped. Each proposal is individually reasonable. Our default answer is still no, and this note is the reasoning behind that default.
What a second datastore actually adds
It is never just the datastore. A new store adds an operational surface: another thing to back up, another thing to monitor, another thing to secure, another failure mode, another version to keep current, another piece of knowledge the team that operates the system has to carry. The feature you wanted is usually small. The operational tax is permanent, and it is paid by whoever runs the system long after the feature shipped.
What a single PostgreSQL buys you
- One consistency model. Data inside one transactional store is consistent by construction. Data split across two stores is consistent only as well as the code that syncs them, which is to say never quite.
- One backup, one restore. A point-in-time restore of PostgreSQL restores everything, coherently, to one moment. A system split across stores has no single coherent moment to restore to; you restore two things and hope they agree.
- More capability than its reputation suggests. PostgreSQL handles document-shaped data with
jsonb, full-text search good enough for most real needs, and event signalling withLISTEN/NOTIFY. It covers a surprising amount of what people reach for a second store to do.
The failure mode of two stores
The specific danger is the dual write. When a single logical change has to land in two stores, there is no transaction spanning both. One write succeeds, the other fails, and the system is now inconsistent in a way nothing will detect until a user notices a wrong number. The reconciliation job written to paper over this is not a fix; it is a second permanent cost, and it is itself a thing that can fail.
When the rule breaks
This is a default, not an absolute. A second store earns its place when two conditions both hold. First, the workload genuinely exceeds what PostgreSQL does well: real full-text search at scale, a caching tier justified by measured load, time-series volume of a kind a relational store handles badly. Second, the new store is treated as derived, never authoritative. PostgreSQL remains the source of truth; the second store is a projection of it that can be flushed and rebuilt at any time. A cache you can drop and repopulate is fine. A second store that owns data nothing else has is the thing to refuse.
The note for the file
"Add a datastore" is an architecture decision wearing the costume of a library choice. The question is not "would Redis make this faster." It is "are we willing to operate a second stateful system, forever, for this." Usually the honest answer is no, and PostgreSQL, used properly rather than used as a plain table store, was already enough.