AI Summary - 20-sec read - Reviewed by experts
- A slow Odoo is not the software being bad - it is almost always a small set of fixable causes, and "buy a bigger server" is usually the wrong first move.
- The most common culprit is worker configuration: too few workers, or a single-process setup, so a handful of users queue behind each other on one CPU.
- The second is the database: an untuned Postgres, missing indexes on the fields you filter and sort by, and list views loading tens of thousands of rows with no limit.
- The rest is self-inflicted - a heavy custom view, an automation firing on every write, a cron job hammering the server during business hours, or a database never cleaned of log bloat.
- Short on time? We will profile your Odoo, find what is actually slow, and fix it. Book a free call.
Short on time? Book a free call.
Your team used to like Odoo. Now every screen takes a beat too long, the sales list spins before it loads, and someone has started saying "the ERP is slow again" in the group chat. The reflex is to blame the software or throw a bigger server at it - and both usually waste money without fixing anything. A slow Odoo is not "just how Odoo is". After enough go-lives and rescues, the causes are boringly predictable: a handful of configuration and database issues that any team can find with the right checks. Here is where the time actually goes, and how to get it back.
First, find out what is actually slow
Do not tune blind. "Odoo is slow" is a feeling; you need a fact. Is one specific screen slow while the rest is fine, or is everything sluggish? Is it slow for everyone at once, or only at 10am when the whole team logs in? Turn on the developer tools and watch how long a page takes and how many database queries it fires - a single list view firing thousands of queries tells you exactly where to look. Check the server: is one CPU pinned at 100% while others idle, is the box swapping because it ran out of RAM, is the database the bottleneck or the application. Ten minutes of looking saves you from "upgrading" a server that was never the problem. Once you know whether it is workers, the database, or a specific customisation, the fix is usually quick.
The worker problem: Odoo is queuing your users
This is the single most common cause of a slow multi-user Odoo, and it is a config line, not a hardware limit. Odoo in production should run in multi-process mode with several workers, each handling requests in parallel. Left on the default single-process setup, or with too few workers, every user request queues behind the others on one CPU core - so five people clicking at once feel like the system has frozen, even on a powerful server. The rule of thumb is roughly two workers per CPU core plus one, with memory limits set so a runaway request is recycled rather than allowed to eat the box. A separate point: long-running jobs and cron should have their own worker so a nightly report cannot starve the people trying to work. Getting worker count, memory limits, and cron isolation right fixes more "Odoo is slow" complaints than any other single change.
Odoo grinding to a halt when the team logs in?
We will check your worker configuration, database, and the specific slow screens, and tell you exactly what to change - often no new hardware needed. No pitch, reply in 2 hrs, no card needed, NDA on request.
Get a free auditThe database: tuning, indexes, and unbounded lists
Odoo is only as fast as the Postgres behind it, and three database issues cause most of the slowness once workers are right.
- An untuned Postgres. The default Postgres config is deliberately conservative and assumes a tiny machine. On a real server it leaves most of your RAM unused. Tuning shared buffers, work memory, and the cache settings to match the hardware often produces a jump in speed for zero code change.
- Missing indexes. When you filter, group, or sort a large table on a field that is not indexed, Postgres scans every row. On a table with hundreds of thousands of records - sale orders, stock moves, journal entries after a few years of trading - that is the difference between instant and a visible wait. Add indexes on the fields your busy screens actually filter and sort by.
- Unbounded list views. A list or a report that pulls tens of thousands of rows with no limit will always be slow, and no amount of tuning saves it. Paginate, add default filters so a screen opens on this month rather than all time, and archive records you no longer touch so the working set stays small.
A slow ERP quietly taxes every hour your team works.
We will profile your Odoo end to end - workers, Postgres, indexes, and the customisations dragging it down - and hand you a fix list ranked by impact. Reply in 2 hrs, NDA on request.
Book a free callThe self-inflicted slowdowns
The last bucket is things added after go-live that quietly cost performance. A custom view that computes a heavy field on every row. An automated action or automation rule that fires on every single write and does real work each time. A scheduled job set to run every few minutes, or during business hours, hammering the server when people are trying to use it. A database that has never been cleaned, so years of log and mail-message bloat sit in the tables the app queries. None of these are Odoo being slow - they are configuration choices that can be fixed once you find them. The same care that goes into a clean implementation is what keeps performance healthy afterwards, which is why we treat tuning as part of a proper Odoo implementation rather than an afterthought, and why messy go-lives so often show up first as slowness - a pattern related to why first reports do not reconcile after go-live.
Takeaways
- A slow Odoo is almost always a fixable config or database issue, not the software - measure before you buy a bigger server.
- The top cause is worker configuration: run multi-process with enough workers and isolated cron, or your users queue on one CPU.
- Tune Postgres to your hardware, index the fields your busy screens filter and sort by, and never let a list load unbounded rows.
- Hunt the self-inflicted causes: heavy custom views, automations firing on every write, badly scheduled cron, and years of table bloat.
- Ten minutes of profiling points you straight at the bottleneck - workers, database, or a specific customisation.
Frequently asked questions
Will a bigger server fix a slow Odoo?
Rarely, and it is the most expensive way to find out. If the real cause is a single-process worker setup, an untuned Postgres, or an unindexed table, a bigger box just idles more capacity while the same bottleneck throttles you. Measure first - check worker config, CPU distribution, and slow queries. More hardware helps only once those are right and you have genuinely outgrown the machine, which is far less often than teams assume.
How many workers should I run?
A common starting point is about two workers per CPU core plus one, with memory limits set so a heavy request gets recycled instead of eating the server. Give long-running jobs and cron their own worker so a nightly process cannot block interactive users. Then watch real usage - if workers are saturated at peak, add more; if the box is swapping, you have too many for the RAM. Tune to your actual load, not a fixed formula.
Is it safe to add database indexes myself?
Adding an index is low-risk and reversible, but do it deliberately: index the fields your slow screens actually filter, group, and sort by, not everything. Over-indexing slows down writes and wastes space. Confirm the win by checking the query before and after. If you are unsure which fields matter or you are on a large production database, have someone experienced review it - the wrong index helps nothing and the right one can be dramatic.
Could a custom module be slowing everything down?
Very often, yes. A custom computed field that runs on every row, an automation that fires on every write, or a poorly written view can drag the whole system down while looking innocent. If Odoo slowed down after a specific customisation went live, that is your first suspect. Profile the affected screens, check how many queries they fire, and review the module. Well-built customisations are fast; the slow ones are usually fixable once identified.
The short version: a slow Odoo is a solvable problem, not a life sentence. Measure to find the real bottleneck, fix your worker configuration so users stop queuing, tune Postgres and index the tables your busy screens hit, and hunt down the heavy views, automations, and cron jobs added after go-live. Most teams get their fast Odoo back without spending a rupee on new hardware.
Leads the Odoo practice at Braincuber. Has delivered Odoo ERP implementations, NetSuite/Tally migrations, and Shopify–Odoo integrations for US mid-market and D2C brands. Owns scoping, data migration, and go-live for every Odoo engagement.