Duration: 25:39
PART 1 — Analytical Summary 🚀
Speaker and context 💬
Nicolas Sahl, a decade-long developer on Odoo’s internal team (which runs and maintains the odoo.com platform), explains how to run multiple PostgreSQL servers behind a single Odoo 19 instance to scale reads while preserving data consistency. The talk balances a strong warning against premature complexity with a pragmatic walkthrough: when vertical scaling tops out, you can distribute read load across replicated databases without changing Odoo’s functional behavior. This matters for high-traffic deployments and large-scale SaaS operators who need more throughput while keeping the platform simple and reliable.
Core ideas and innovations ⚙️
With Odoo 19, a single Odoo instance can connect to one primary read-write PostgreSQL server and one or more read-only replicas (via standard PostgreSQL streaming replication). There is no external middleware: everything relies on built-in PostgreSQL streaming replication and Odoo’s new routing hints that try eligible operations on read-only nodes first. The replication model is strictly single-writer: all servers hold the full database, indexes, and data; there is no sharding and no multi-master. The architecture aims to split CPU and some I/O load by offloading reads, while writes continue to go through the primary.
Nicolas distinguishes asynchronous versus synchronous replication. Asynchronous is mainstream: the primary commits locally and streams changes to replicas eventually. Synchronous replication waits for commits to be acknowledged by a configured number of standbys—ensuring read-after-write consistency at the cost of added latency and a larger failure domain. He stresses that synchronous setups require careful monitoring and clear failover behavior (e.g., ordered lists of synchronous standbys, and awareness that losing too many synchronous nodes can halt commits). In practice, you often start with asynchronous replication, observe, and consider synchronous only when the use case and reliability tooling justify it.
On the Odoo side, every HTTP/RPC call is a single PostgreSQL transaction that must run entirely on either the primary or a replica—never split. Odoo now provides early routing signals:
- In web controllers, a read_only=True parameter marks the entire request as read-only.
- On models, the @api.readonly decorator marks method calls as read-only candidates.
If a supposedly read-only transaction attempts a write, Odoo logs an error and transparently retries the entire transaction on the primary (you lose time in that case). Odoo also handles replica failures by closing connections and routing all traffic to the primary; it periodically retries the replica connection (default: every ~20 minutes) and new workers will attempt to connect afresh.
Nicolas calls out a critical code hygiene point: avoid database safe points in this architecture. Savepoints consume transaction IDs and are tracked in a small LRU; on replicas, exhausting that LRU forces repeated disk checks, crushing performance. Clean code and indexing come first; horizontal database scaling is a last resort after vertical scaling and database tuning.
Impact and takeaways 🧠💼
The tangible benefit is straightforward: scale reads by adding PostgreSQL replicas and let Odoo 19 route suitable read-only transactions automatically. This can lift throughput for dashboards, search/read operations, and similar workloads—many core endpoints (e.g., search_read, web client read flows) are already marked as read-only in standard code. However, the solution does not increase write capacity, does not reduce your total storage footprint, and adds operational complexity (replication health, latency sensitivity, commit quorum logic). It also does not solve attachment storage or sessions by itself; those remain file-based (you can use shared storage or community modules like OCA session_db for DB-backed sessions).
Nicolas’s operational guidance is very pragmatic:
- Prefer vertical scaling first—fewer moving parts, easier to reason about, and often sufficient.
- When going horizontal for reads, keep it simple: standard streaming replication, single-writer, and minimal middleware.
- Be explicit in code about read-only logic, eliminate savepoints, and monitor replication health closely.
- In Odoo configuration, you add the read-only replica host/port; while Odoo expects a single replica endpoint, you can front it with DNS round-robin or connection poolers like PgBouncer if needed.
A note on Odoo.sh: this read-replica pattern isn’t offered on Odoo.sh. Odoo.sh supports very large vertical instances (up to 256 CPUs per node) and uses shared PostgreSQL clusters; streaming replication can’t be exposed per-tenant, and database ports are not opened. For BI mirroring from Odoo.sh, the practical path is to automate restoring periodic backups on your own infra.
Bottom line: Odoo 19 + PostgreSQL streaming replicas provide a clean, built-in path to read scaling with strong consistency options. Use it when you’ve exhausted simpler options, and treat synchronous replication as a carefully monitored, latency-sensitive choice rather than a default. ⚖️
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo’s vision.
Our philosophy hasn’t changed: start simple, scale when necessary, and keep the tools integrated. With Odoo 19, we wanted a pragmatic path to read scalability that respects PostgreSQL’s strengths. One writer, many readers, and clear signals from Odoo to route work—this keeps deployments understandable for teams while unlocking meaningful performance gains.
The community taught us that reliability is about restraint as much as features. If you can solve it by tuning, indexing, or a bigger box—do that first. When you need more, replicas and read-only routing are there, built on standard PostgreSQL, with the same openness and simplicity Odoo is known for.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Odoo’s approach is disciplined: single-writer PostgreSQL with read replicas and application-level hints is a proven pattern. For mid-market workloads, it balances cost, simplicity, and performance effectively. The emphasis on built-in database features and minimal middleware will resonate with teams that value operational clarity and developer ergonomics.
At larger enterprise scales, questions emerge around write scalability, synchronous commit latencies across regions, and orchestration of failover—areas where customers may expect ecosystem tooling (e.g., managed HA services, automated quorum management, compliance controls). Governance, auditing, and regional data residency also matter. Still, as a UX-forward, integrated suite, Odoo’s design coherence is a competitive differentiator; the challenge will be codifying robust HA playbooks (Patroni/Pacemaker-equivalents, managed cloud options) without compromising the product’s hallmark simplicity.
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.