Odoo Performance · intro · 8 min read
Common Odoo Performance Mistakes
Frequent causes of slow Odoo in production: hardware-first fixes, ORM anti-patterns, cron pile-ups, unindexed custom fields, and integration designs that ignore backpressure.
Last reviewed 2026-07-30 · Estimated effort: 1–2 weeks typical discovery
Table of contents
The most expensive mistake is scaling infrastructure before profiling application and integration hotspots — bigger VMs mask N+1 loops until data volume doubles again.
Customization without volume assumptions adds computes, constraints, and automations on high-frequency models. Migration without performance regression testing ships new ORM behavior into production blindly.
Operational mistakes — overlapping crons, unbounded queue retries, reporting during pick peaks — hurt as much as code defects and are faster to fix once recognized.
Performance postmortems across retail, logistics, and integrated ecommerce estates repeat the same themes. Naming them early saves months of frustration and unplanned rescue work.
This article catalogs common Odoo performance mistakes with pointers to remediation articles. Use it in customization reviews, go-live checklists, and upgrade planning workshops.
Teams upgrade CPU and RAM when users report slowness but skip pg_stat_statements and ORM profiling. If workers are idle while users wait, the bottleneck is likely SQL or Python — not GHz.
Conversely, adding workers without connection pool headroom increases lock contention and memory use without improving p95 latency.
Non-stored computed fields on list views, constraints that search unrelated tables on every write, and studio automations chaining without limit are frequent Customization outcomes that degrade at scale.
Third-party modules stacked on sale.order and stock.picking without review multiply inherited compute cost — treat module count on hot models as a performance risk register entry.
- ▸Loop with search inside integration import
- ▸Onchange calling external API synchronously
- ▸Server actions running Python on mass mailings hourly
- ▸Tracking on high-volume fields without need
Every scheduled action set to run every minute because once it was fast on demo data. Webhook handlers that import entire orders synchronously. Connectors without external IDs retrying into duplicate documents and duplicate load.
See background jobs and API articles for channel design; see Shopify pillar when ecommerce drives the flood.
Years of mail_message and attachment growth without archival. Custom filter fields without indexes added before go-live. BI tools hammering primary PostgreSQL with unoptimized joins.
Post-Migration, teams skip re-benchmarking because functional tests passed — performance regressions are non-functional until month-end.
No owner for connector lag metrics. No performance acceptance criteria in UAT. Developers deploy Friday without rollback plan while cron and queue load peaks Saturday.
Fix ownership: name module owners, integration owners, and infra owners in runbooks — mistakes recur when everyone assumes someone else watches queue depth.
- ✓Add performance acceptance criteria to customization and go-live checklists.
- ✓Profile on staging with production-scale record counts before approve.
- ✓Require external IDs and queue handoff in every integration design review.
- ✓Re-benchmark named workflows after every Migration release.
- ✓Review cron registry quarterly and disable orphaned jobs.
- ✓Teach stakeholders that fast and wrong is not a performance win.
- !Buying hardware before a one-week diagnosis sprint.
- !Adding indexes in production without EXPLAIN on staging.
- !Disabling audit or security rules permanently for speed.
- !Assuming Odoo Online and on-premise need identical tuning playbooks.
- !Testing performance only with admin user on empty database.
- !Treating performance as one-time project instead of ongoing ops discipline.
Most Odoo performance pain comes from repeatable mistakes — infrastructure guesses, ORM anti-patterns, schedule pile-ups, and missing post-upgrade benchmarks.
Next, choose a performance strategy that sequences fixes by impact instead of chasing every symptom at once.
| Option | Best when | Trade-off |
|---|---|---|
| Configure | Standard Odoo covers the need | Limited uniqueness |
| Customize | Differentiating workflow | Upgrade cost |
| Integrate | External system of record | Sync complexity |
- Owners named
- UAT scripts signed
- Rollback documented
- Hypercare roster ready
Frequently asked questions
What is the single most common technical mistake?
N+1 ORM patterns in custom modules and connectors — linear query growth with line count on orders and pickings.
How do customizations cause slowness without bad intent?
Business rules added incrementally — each sensible alone — stack computes and automations on the same model. Customization pillar helps prioritize rules; performance testing validates volume.
When is slowness actually a Migration issue?
When the same workflow regressed immediately after upgrade with no new modules. Compare query plans and ORM behavior pre/post — Migration testing should include performance cases.
Can we fix mistakes without rewriting everything?
Often yes. Rank by impact: one index, one cron reschedule, or one connector batch change can restore acceptable service before deeper refactors.
Related articles
Diagnosing Slow Odoo Systems
A step-by-step audit for slow Odoo: reproduce symptoms, profile requests, inspect SQL, check workers and queues, and isolate custom module cost.
View →ORM Performance Best Practices
Odoo ORM patterns that scale: batch operations, prefetch, domain design, computed fields, and avoiding N+1 on sale, stock, and accounting paths.
View →Choosing the Right Performance Strategy
Prioritize Odoo performance work: audit-first vs rescue, quick wins vs refactors, infra vs application, and phased roadmaps aligned to business calendars.
View →Monitoring Odoo in Production
Observability for live Odoo: RPC latency, worker health, PostgreSQL metrics, queue lag, cron duration, and alerting runbooks tied to business workflows.
View →Related services
Odoo Rescue
Audit-first recovery when performance incidents block go-live or peak season.
View →Odoo Performance Optimization
Diagnosis and remediation for slow production Odoo — ORM, workers, and operations.
View →Dedicated Odoo Developer
Reserved capacity for profiling, module fixes, and performance backlog.
View →Recognize these patterns in your estate?
Describe recent incidents and customization history — we will help prioritize fixes with highest user impact.
