NetBox ↔ PostgreSQL Read‑Only Replica: Offloading Reads for Low‑Traffic Workloads

Answer: NetBox does not supply a built‑in read‑replica router

As of the current NetBox releases, the framework provides no automatic router that directs SELECT statements to a PostgreSQL replica. You must define a custom database router class and add it to DATABASE_ROUTERS while setting READ_REPLICA_URL in DATABASES.

Steps to enable read‑only replica usage

• Add a replica entry to DATABASES (e.g., replica) with the READ_REPLICA_URL pointing to the standby.
• Create a simple router, for example:

• class ReadReplicaRouter:
      def db_for_read(self, model, **hints):
          return 'replica' if settings.READ_REPLICA_URL else 'default'
      def db_for_write(self, model, **hints):
          return 'default'
      def allow_relation(self, obj1, obj2, **hints):
          db_set = {'default', 'replica'}
          return obj1._state.db in db_set and obj2._state.db in db_set
      def allow_migrate(self, db, app_label, model_name=None, **hints):
          return db == 'default'
  

• Add the router to DATABASE_ROUTERS in configuration.py.

Performance impact of the custom router

The router adds only a few attribute look‑ups per request (typically db_for_read and db_for_write). This overhead is far below the cost of establishing a database connection and is negligible compared with query execution time. It does not interfere with Django’s native connection pooling.

Acceptable replication lag for low‑traffic workloads

For change‑management views that tolerate brief staleness, a lag of roughly 2‑5 seconds is generally acceptable. UI elements may show recently created or updated objects slightly delayed, but core functionality remains intact. Monitor lag with PostgreSQL’s pg_stat_replication or tools like check_postgres replication lag.

If your workflow requires sub‑second consistency (e.g., real‑time validation of newly created devices), please confirm that tolerance, as a replica may not be suitable in that case.