ORM Performance Best Practices

Introduction#

Custom modules often work fine on demo data then collapse when a pick list touches five hundred moves or a connector imports ten thousand order lines. The ORM is rarely the villain — usage patterns are.

This article collects Odoo-specific ORM practices for production modules. Pair with database optimization when domains need indexes and with API optimization when RPC payloads repeat the same anti-patterns.

Prefer batch reads with explicit fields#

Use search_read or read with a minimal field list instead of browsing large recordsets and accessing fields lazily. For list views and exports, fetch only columns you render or compute downstream.

When iterating records, reuse prefetched recordsets: browse(ids) once, then map related data with read_group or a single related search rather than per-row search calls.

• ▸search_read with fields=[] for integrations and reports
• ▸Avoid len(recordset) triggers that fetch entire tables
• ▸Use read_group for aggregates instead of Python loops
• ▸Split giant exports into chunked jobs with queue workers

Write and create in batches#

create multi-record dicts in one call where business rules allow. For updates, group by identical vals and use write on recordsets rather than looping single-record writes that retrigger full constraint stacks.

Heavy side effects belong in deferred jobs — not in create overrides on high-volume models like stock.move or account.move.line.

Computed and related fields#

Prefer stored computed fields with explicit @api.depends when values are read often and change infrequently. Non-stored computes on list views force recalculation for every row on every load.

Inverse methods and related fields that chain across many2many relations can trigger cascade recomputes. Scope depends carefully and test with production-sized recordsets on staging.

Domains, search, and indexes#

Every frequent domain filter should map to a indexed column or a stored related field. ILIKE scans on name fields without trigram support do not scale for autocomplete on large partners or products.

Avoid OR domains across unrelated columns when a single stored flag or category field can narrow the set. The database optimization article covers PostgreSQL indexes aligned to Odoo models.

Code review checklist for hot paths#

Flag loops containing search, browse, or env.ref inside integrations, picking validation, and invoice posting. Require proof of query count or profiling output for changes touching sale.order, stock.picking, or account.move.

Customizations requested through functional specs should include expected volume — orders per hour, lines per pick — so ORM design is sized intentionally. Link Customization when business rules demand expensive checks.

Practical recommendations#

• ✓Set a module review gate for ORM patterns on high-volume models.
• ✓Require profiling evidence for any new compute on list-visible fields.
• ✓Use queue jobs for bulk creates and updates from integrations.
• ✓Store frequently filtered values instead of computing them on read.
• ✓Document expected transaction volume in customization specs.
• ✓Train integrators to use search_read with field lists in connectors.

Common mistakes#

• !Calling search([]) or browse loop per order line in connectors.
• !Non-stored compute on fields shown in default list views.
• !Using name_search with leading wildcard on million-row tables.
• !Triggering full reconciliation logic on every write via broad @api.constrains.
• !Mixing sudo() with unbounded domains in cron jobs.
• !Assuming prefetch covers fields never loaded in the initial read.

Conclusion#

ORM performance is a design discipline: batch reads and writes, stored computes where lists demand them, and domains that PostgreSQL can index.

Next, align database indexes and vacuum health with the domains and models your modules hit hardest.