Odoo sépare déjà lectures et écritures : la base de la v20

Quand une instance Odoo ralentit sur les rapports et les tableaux de bord, le réflexe consiste souvent à ajouter du CPU ou à passer à une offre supérieure. Il existe pourtant un levier moins connu, présent dans le cœur d'Odoo depuis la version 18 : router les requêtes de lecture vers une réplica PostgreSQL, et réserver la base primaire aux écritures. La fonction est peu documentée côté grand public, alors qu'elle constitue la brique de montée en charge sur laquelle Odoo appuie une partie de son discours pour la version 20.

Ce que fait le paramètre db_replica_host

Le principe repose sur deux paramètres ajoutés au fichier odoo.conf : db_replica_host et db_replica_port¹. La configuration classique garde db_host et db_port pointés sur la base primaire, celle qui accepte les écritures, et ajoute l'adresse d'une réplica en lecture seule.

À partir de là, Odoo dirige les requêtes SELECT vers la réplica et laisse les INSERT, UPDATE et DELETE sur la primaire. Concrètement, un utilisateur qui consulte un pivot de ventes ou un état de stock interroge la réplica, pendant qu'un autre valide une facture sur la primaire. La base d'écriture se concentre sur son travail, la lecture n'entre plus en concurrence avec elle. La documentation du framework précise que le mécanisme n'est disponible que sur Odoo 18 et versions suivantes².

La réplica elle-même n'a rien de spécifique à Odoo. Il s'agit d'une réplication PostgreSQL en streaming standard : la primaire transmet ses journaux de transactions (WAL) à la réplica qui les rejoue en continu, avec wal_level=replica, plusieurs wal_senders et le hot_standby activé³. Odoo se contente de poser une couche de routage au-dessus.

Comment vérifier que le routage fonctionne

Le point pratique le plus utile tient dans les logs. Chaque requête HTTP se termine par un suffixe rw ou ro dans la trace d'accès². Une ligne marquée ro confirme que la lecture est bien partie sur la réplica, une ligne rw indique un passage par la primaire. C'est le moyen le plus direct de valider que la séparation opère réellement, sans se fier à une intuition.

En complément, un outil comme pg_activity permet de regarder l'activité de chaque serveur PostgreSQL séparément et de voir la charge de lecture basculer vers la réplica après activation. Si tout reste sur la primaire, la configuration n'est pas prise en compte et il faut revenir au fichier odoo.conf.

Les limites qui coincent en production

Deux contraintes méritent d'être posées avant de déployer. La première concerne le nombre de réplicas. Odoo n'accepte qu'un seul db_replica_host. Pour répartir la lecture sur plusieurs réplicas, il faut placer un répartiteur de charge, par exemple HAProxy, devant elles et pointer Odoo sur ce répartiteur⁴. La gestion du parc de réplicas sort alors du périmètre d'Odoo et redevient un sujet d'infrastructure classique.

La seconde contrainte est plus insidieuse. Une réplication en streaming introduit un léger décalage entre l'écriture sur la primaire et sa disponibilité sur la réplica. Si une lecture immédiate arrive avant que la réplica ait rejoué la transaction, Odoo peut renvoyer des données périmées ou lever une erreur. Les retours de terrain insistent sur ce point : la séparation lecture/écriture exige de garantir une cohérence forte, faute de quoi l'application produit des incohérences⁴. Ce n'est pas une raison pour renoncer, mais cela oriente vers les instances où la lecture domine largement, comme le reporting et les consultations.

Le lien avec Odoo 20

Odoo maintient une cadence de versions intermédiaires, avec une 19.4 livrée en juillet 2026 côté Odoo Online⁵. La version majeure suivante est attendue à l'Odoo Experience de Bruxelles, prévu du 24 au 26 septembre 2026, la disponibilité générale suivant quelques semaines après la conférence⁶.

Plusieurs partenaires présentent la réplica en lecture comme un pilier de la scalabilité d'Odoo 20 et avancent des ordres de grandeur, par exemple plus de 10 000 utilisateurs simultanés visés contre 2 000 à 5 000 sur les versions actuelles. Ces chiffres proviennent d'analyses de partenaires, pas d'un communiqué officiel d'Odoo, et restent à confirmer. Le fait vérifiable, lui, est que la brique technique existe déjà et fonctionne dès la v18.

Notre lecture

Pour une PME sur une instance unique bien dimensionnée, activer une réplica n'apporte rien et ajoute une pièce à surveiller. L'intérêt commence quand le reporting pèse sur les opérations quotidiennes, ou quand un ETI approche du plafond de sa base primaire. Dans ces cas, la séparation lecture/écriture achète du temps avant un changement d'échelle plus lourd.

Notre conseil de praticien : traiter cette fonction comme un sujet d'exploitation, pas comme une case à cocher. La cohérence des données et la supervision de la réplica demandent un vrai suivi. Avant de miser sur les promesses de montée en charge d'Odoo 20, il est plus rentable de mesurer où votre instance souffre aujourd'hui, puis de tester le routage ro sur un environnement de préproduction. La même logique de lecture seule anime d'ailleurs le serveur MCP natif d'Odoo, que nous avons regardé dans notre analyse dédiée.

Sources

• Odoo primary/replica database guide (mhch-odoo) : https://github.com/mhch-odoo/odoo_replica_database
• PostgreSQL streaming replication for Odoo 19 (long-dn) : https://github.com/long-dn/odoo-psql-replication
• Deployment of Odoo in High Availability (forum Odoo) : https://www.odoo.com/forum/help-1/deployment-of-odoo-in-high-availability-292867
• Odoo Release Notes : https://www.odoo.com/page/release-notes
• Odoo 20 Preview: Features, AI & Roadmap 2026 (OBS Solutions) : https://www.odoo-bs.com/blog/global-5/odoo-20-preview-493