Handle updates to denormalized data via PostgreSQL triggers #420

New Issue

MrUnknownDE · 2026-04-05T16:31:29+02:00

MrUnknownDE commented

2026-04-05 16:31:29 +02:00

Originally created by @jeremystretch on 2/4/2026

NetBox Version

v4.5.2

Python Version

3.12

Area(s) of Concern

User Interface
REST API
GraphQL API
Python ORM
Other

Details

There are several instances throughout NetBox where we store denormalized data from related objects locally performance reasons. For example, the region and site group for the site to which a prefix is assigned are stored locally in the ipam_prefix table to enable efficient filtering. These stored values must be updated automatically in response to changes on the related object.

Currently, this is handled in Python via the register and the update_denormalized_fields() signal handler. When the post_save signal fires for an object, any registered denormalized fields are updated in a synchronous (blocking) operation.

We could move this logic from the application code to a series of PostgreSQL triggers which live in the database itself. This would remove the dependence on application-level signal handling and likely yield better performance in general. This approach comprises two components:

PostgreSQL functions to update database records
PostgreSQL triggers to execute the function is response to changes

While it's feasible to create functions and triggers using raw SQL in migrations, we should consider using a library such as django-pgtrigger to simplify their management.

*Originally created by @jeremystretch on 2/4/2026* ### NetBox Version v4.5.2 ### Python Version 3.12 ### Area(s) of Concern - [ ] User Interface - [ ] REST API - [ ] GraphQL API - [ ] Python ORM - [x] Other ### Details There are several instances throughout NetBox where we store denormalized data from related objects locally performance reasons. For example, the region and site group for the site to which a prefix is assigned are stored locally in the `ipam_prefix` table to enable efficient filtering. These stored values must be updated automatically in response to changes on the related object. Currently, this is handled in Python via the register and the [`update_denormalized_fields()`](https://github.com/netbox-community/netbox/blob/ee6cbdcefe1c522d718e880ea3f955e7683f2b9b/netbox/netbox/denormalized.py#L32) signal handler. When the `post_save` signal fires for an object, any registered denormalized fields are updated in a synchronous (blocking) operation. We could move this logic from the application code to a series of [PostgreSQL triggers](https://www.postgresql.org/docs/8.1/triggers.html) which live in the database itself. This would remove the dependence on application-level signal handling and likely yield better performance in general. This approach comprises two components: * PostgreSQL functions to update database records * PostgreSQL triggers to execute the function is response to changes While it's feasible to create functions and triggers using raw SQL in migrations, we should consider using a library such as [django-pgtrigger](https://django-pgtrigger.readthedocs.io/) to simplify their management.

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label complexity: high complexity: high complexity: high netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#420