Odoo is incredibly fast out of the box. But as your data grows, standard configurations begin to fail. Here is what we typically find during a performance audit.
A poorly written custom module might execute 1,000 separate queries just to load a list of 1,000 sales orders. We rewrite these using bulk prefetching.
When searching for a product by barcode, Postgres scans the entire table instead of using an index. We analyze query logs to add missing B-Tree indexes.
Odoo's default PostgreSQL config assumes it's running on a tiny 2GB server. We tune `shared_buffers` and `effective_cache_size` to actually use your expensive server RAM.
If workers consume too much RAM, the OS violently kills them (Out of Memory). We adjust `limit_memory_hard` to recycle workers gracefully before they crash.
Fields that calculate their value on-the-fly (like total margins) can freeze a page. We convert these to `store=True` so they only calculate when updated.
Storing millions of images directly on the web server causes I/O bottlenecks. We offload your filestore to AWS S3, freeing up the disk to focus on database reads.
We inject performance at every level of the stack, from the proxy down to the physical disk.
Their checkout page was taking 8 seconds to load, killing conversions. We traced the issue to a custom pricing rule executing 400 queries. By refactoring the Python logic and adding Redis, load time dropped to 0.8s.
Searching for a tracking number took 15 seconds. Standard Odoo indexes couldn't handle a table with 50 million rows. We created partial covering indexes in PostgreSQL, reducing search time to 40 milliseconds.
A client had 300 users logging in at 9:00 AM every day, crashing the server with "Too Many Connections". We implemented pgBouncer to multiplex 50 real database connections across 500 virtual ones, solving the crashes entirely.
The finance team couldn't run the end-of-month valuation report—it would just time out. We converted on-the-fly computations to stored fields and optimized the SQL view, allowing the report to generate in 12 seconds.
Scaling vertically (buying more CPU/RAM) is a temporary bandage. If your code executes an O(N^2) loop, throwing twice the CPU at it will only buy you a few months. You must fix the root bottlenecks first.
Typically 3 to 5 days. We install Datadog or pg_stat_statements, let it collect real-world traffic data, and then present a detailed report of the exact queries and Python functions causing the lag.
Odoo.sh is a Platform-as-a-Service, so we don't have root server access. However, we CAN optimize the Python code, fix bad queries, and add database indexes, which solves 80% of Odoo.sh performance issues.
Yes, but it must be configured in `transaction` pooling mode, and Odoo must be configured to support it. If done incorrectly, user sessions will cross-pollinate. We have deployed it safely for dozens of enterprise clients.
Every second your employees spend waiting for a page to load is wasted payroll. Let us tune your system to maximum performance.