Khichdi InfoTech
Skip to content

Odoo Performance · intermediate · 9 min read

Caching Strategies

Layered caching for Odoo: ORM cache behavior, HTTP reverse proxy, CDN static assets, session considerations, and safe invalidation when master data changes.

Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice

Table of contents

Caching in Odoo spans multiple layers: per-request ORM cache inside workers, optional distributed cache for session or computed fragments, HTTP caching for anonymous website pages, and CDN delivery for static assets.

Wrong cache scope causes stale prices, wrong stock on the storefront, or users seeing other companies' data — invalidation rules must tie to product, pricelist, and warehouse write events.

Caching complements — does not replace — ORM and database fixes. A cached slow query is still slow on miss and expensive to invalidate at scale.

Teams enable aggressive HTTP cache after a marketing deadline then discover checkout showed yesterday's promotion. Cache wins require explicit ownership of what is cached, for whom, and what event clears it.

This article describes safe caching patterns for Odoo estates. Start with static assets and anonymous catalog pages; add application-level cache only with clear invalidation tied to business writes.

Each Odoo worker maintains an ORM cache for the lifetime of a request (and related prefetch). Long-running jobs or wizards that browse huge recordsets inflate worker memory — split work or use streaming exports instead of holding entire tables in cache.

Repeated identical RPC in one request benefit automatically; cross-request application cache requires custom design with TTL and invalidation — use sparingly on multi-worker estates.

Varnish, NGINX, or Cloudflare can cache anonymous GET responses for website routes when Set-Cookie and Vary headers are correct. Never cache responses that embed user-specific pricelist or cart state without variant keys.

Use short TTL with stale-while-revalidate for catalog pages if occasional minute-level lag is acceptable. Checkout and /my account paths must bypass cache entirely.

  • Cache only GET routes without session personalization
  • Respect Cache-Control from Odoo or override with policy docs
  • Purge on product publish and pricelist change events
  • Test cache with multiple pricelists and companies

Serve /web/static and theme assets from CDN with fingerprinted URLs. Large product images benefit from CDN edge caching and compression — coordinate with website performance guidance on image sizing at source.

Attachments with sensitive documents should not use public CDN URLs without access control review.

Define invalidation triggers: product write, stock quant change below threshold, pricelist item update. Automate purge webhooks to CDN or proxy when connectors bulk-update catalog.

For integrated Shopify storefronts, cache strategy may live primarily on Shopify — Odoo cache still matters for portal, reports, and API consumers.

  • Document cache scope per route and environment before enabling proxy cache.
  • Start with CDN on static assets — highest gain, lowest stale-data risk.
  • Automate purge hooks on catalog and pricing maintenance windows.
  • Monitor cache hit rate alongside error reports for stale content.
  • Never cache RPC or JSON routes used by live integrations without analysis.
  • Pair cache rollout with website performance testing on mobile networks.

  • !Caching authenticated shop pages with a single cache key.
  • !Ignoring Vary headers and serving wrong language or currency.
  • !Long TTL on promotional pages without purge runbook.
  • !Using cache to hide ORM problems that fire on every cache miss.
  • !Clearing entire CDN on every minor product text edit.
  • !Assuming single-worker dev behavior matches multi-worker production.

Effective Odoo caching is layered, conservative on personalized routes, and paired with automated invalidation when master data changes.

Next, review API and integration paths that should never be cached without explicit contract.

Browser, CDN, reverse proxy, Odoo workers, PostgreSQL with cache boundaries.
  • Client / Channel

    Users & devices

  • Odoo Application

    Business logic

  • PostgreSQL

    System of record

  • Workers / Cron

    Async work

  • clientapp(HTTP)
  • appdb(ORM)
  • appjobs(queue)
Product write event triggering CDN and proxy purge.
1

Trigger

Business event starts the flow.

2

Execute

Operate in the system of record.

3

Validate

Check outcomes and exceptions.

4

Close

Reconcile and hand off.

Frequently asked questions

Do we need Redis for Odoo caching?

Standard multi-worker Odoo does not require Redis for core operation. Redis helps for session storage, rate limiting, or custom shared cache — evaluate need against complexity.

How do we purge cache after bulk price update?

Automate purge API calls to your CDN or proxy as part of the maintenance job, or use short TTL during known update windows with monitoring for stale hits.

Does caching help API integrations?

Integrations need fresh data — cache external responses briefly for reference data only. Order and stock paths should not rely on stale cache without explicit business approval.

Planning cache layers for Odoo?

Describe your storefront setup, update frequency, and proxy stack — we will suggest safe cache boundaries and purge rules.

Business technology and software delivery