Why Is Your Odoo So Slow at Hundreds of GB? 5 Reasons (and How Xerpium Cuts 30 Minutes to 1)

If you run Odoo on a database that has grown into the hundreds of gigabytes, you already know the symptom: reports that once loaded instantly now take minutes, list views stall, and your accounting team quietly stops trusting the system. The uncomfortable truth is that Odoo doesn't get slow because you did something wrong — it gets slow because the architecture that makes Odoo elegant for small and mid-sized data becomes a liability at scale.

Below are the five technical reasons Odoo slows down at high data volumes, followed by how Xerpium rewrites the rules — modifying the Odoo ORM and leveraging PostgreSQL stored procedures with direct SQL to take heavy queries from roughly 30 minutes down to just 1 minute.

1. The ORM Abstraction Layer Adds Overhead on Every Record

Odoo's Object-Relational Mapping (ORM) is one of its greatest strengths. It lets developers work with Python objects instead of raw SQL, enforces access rules, triggers computed fields, and keeps business logic clean and portable. But every one of those conveniences has a cost.

When you read records through the ORM, each recordset carries Python-level processing: field type conversion, access-rights checks, ir.rule record-level security evaluation, computed-field dependency resolution, and prefetch logic. On a few thousand records, this overhead is invisible. On datasets spanning hundreds of GB — millions of rows across journal entries, stock moves, and analytic lines — that per-record Python work accumulates into minutes of wall-clock time.

The ORM is essentially translating, validating, and marshalling data in the application layer when the database could do the same work far more efficiently in its own engine.

2. The N+1 Query Problem Multiplies Database Round-Trips

The single most common performance killer in Odoo at scale is the N+1 query pattern. It happens when your code loads a set of N records, then loops over them and accesses a related field — triggering one additional query per record.

Suppose you load 100,000 invoices and, for each, access the partner, the currency, and the related analytic account. Even with Odoo's prefetching, poorly designed custom modules or deep relational chains can generate an enormous number of individual SQL statements. Each query is a separate round-trip between the Python worker and PostgreSQL: connection handling, query planning, result serialization, and network latency — repeated thousands of times.

At small volumes, prefetch batching hides this. At high volumes, especially across many-to-many and computed relations, the round-trips explode. Your CPU isn't even the bottleneck — it's the sheer number of conversations between the application and the database.

3. Computed Fields and Stored Dependencies Recalculate at Scale

Odoo's computed fields are powerful: define a dependency, and the framework keeps the value fresh automatically. But store=True computed fields trigger recomputation whenever a dependency changes, and non-stored computed fields recalculate on every read.

In a large database, a single write can cascade into recomputation across huge related sets. Run a mass operation — revaluing inventory, reconciling thousands of entries, recomputing margins — and the ORM dutifully walks the dependency graph in Python, record by record. What should be a set-based database operation becomes an iterative application-layer crawl. This is why "simple" bulk actions can hang for minutes or trigger worker timeouts.

4. Record-Level Security and Access Rules Filter in Layers

Multi-company and multi-user Odoo deployments rely on ir.rule record rules and access control lists to enforce who sees what. These rules are injected into queries as additional WHERE conditions and, in some cases, evaluated in Python.

On large tables, these layered security filters prevent PostgreSQL from choosing optimal execution plans. Complex rule combinations produce convoluted SQL that scans more rows than necessary, ignores otherwise-usable indexes, or forces expensive joins. The security model that protects your data at small scale quietly sabotages your query planner at large scale.

5. Generic SQL Can't Be Tuned for Your Heaviest Reports

The ORM generates SQL dynamically to stay database-agnostic and flexible. That flexibility means it almost never produces the optimal query for your specific, heaviest workloads — the consolidated financial report, the full-history stock valuation, the cross-company analytic dashboard.

These reports aggregate across massive tables with grouping, filtering, and multi-table joins. A hand-tuned SQL statement — using the right indexes, window functions, and aggregation strategy — can outperform generic ORM-generated SQL by orders of magnitude. But out of the box, Odoo never writes that query for you, because it can't know which workload matters most to your business.

The Xerpium Solution: Modify the ORM, Push Heavy Work to PostgreSQL

This is exactly where Xerpium changes the equation. Instead of accepting ORM overhead as a fixed cost, Xerpium modifies the Odoo ORM and leverages PostgreSQL stored procedures with direct SQL for heavy queries — taking operations that previously ran in roughly 30 minutes down to about 1 minute.

The technical principle is simple but transformative: move the work to where the data lives.

• Bypassing ORM overhead. For identified heavy operations, Xerpium replaces the per-record Python processing with direct SQL execution. Instead of instantiating millions of Python objects and running field conversion, prefetch, and recompute logic on each, the data is processed in a single set-based database operation.

• Eliminating the N+1 problem. By executing logic inside PostgreSQL stored procedures, the thousands of individual round-trips collapse into one call. The database joins, filters, and aggregates everything internally and returns a single, finished result set — no repeated application-to-database conversations.

• Executing on the database side. PostgreSQL is purpose-built for set-based data processing: its query planner, indexes, aggregation engine, and caching are vastly more efficient at crunching large volumes than iterative Python. Stored procedures run close to the data with full access to the planner's optimizations and hand-tuned SQL designed specifically for your heaviest reports.

The result is a system that keeps Odoo's flexible ORM for everyday transactional work — where its conveniences matter — while routing the brutal, high-volume queries through optimized SQL that runs where it belongs: inside the database engine.

Stop Waiting on Reports That Should Take Seconds

Hundreds of gigabytes doesn't have to mean half-hour report runs and timed-out workers. With Xerpium's ORM modifications and PostgreSQL stored-procedure engine, your heaviest Odoo operations finish in a fraction of the time — without abandoning the platform your business is built on.

See how much time your team could reclaim. Visit [xerpium.com](https://xerpium.com) to learn more.