Release dbportal 0.2.3 · klinux/dbportal

The audit record built for growth, on top of 0.2.2.

The audit record, partitioned

On PostgreSQL audit_events is partitioned by range on ts: a month per partition (audit_events_p2026_09) by default, or a week from Monday with AUDIT_PARTITION=week. The primary key is (ts, id).
The current period's partition and the next two exist after every boot; a daily audit-partitions job, handed to the queue by the scheduler leader, keeps them ahead; an append whose instant no partition holds makes one on the spot, so no event is lost at a boundary.
Retention (AUDIT_RETENTION_DAYS) drops a partition whole once it is wholly past, instead of deleting rows: instant, no bloat.
Upgrading an existing store: the first boot of this version renames the plain table and attaches it, in one transaction and with no copy, as the audit_events_legacy partition holding everything up to the end of the current period; its old rows are the only ones still deleted, until it can go whole. Verified in CI against a real PostgreSQL, the migration path included.
Without a filter the admin trail's total is the planner's estimate once the table holds more than a hundred thousand rows; a filtered count stays exact and, with a period, touches only that period's partitions.
SQLite keeps one table and prunes by row.

A sticky # column numbers every result row by its position in the order shown; a sort or a filter renumbers from 1. Not a data column: exports, filters and sorting never see it.

Image ghcr.io/klinux/dbportal:0.2.3, signed keyless with SBOM and provenance. Helm chart charts/dbportal 0.1.5 (appVersion 0.2.3).
New, optional: AUDIT_PARTITION=month|week. Admin → Jobs shows the daily audit-partitions job and its result (created, dropped, removed).