railiance-platform/docs/evidence/core-hub-postgres-capacity-admission-2026-08-20.md

Core Hub PostgreSQL capacity admission — 2026-08-20

Workplan: RPF-WP-0021-T02

Target: railiance01 databases/platform-pg

Mode: bounded live occupancy probe; no application data or credential value was read or recorded.

Question

Can Core Hub occupy the fourth and final declaration slot on platform-pg without raising the current 1Gi pod limit or exceeding the explicit 100-connection aggregate?

The four declarations are audit-core, tenant-engine, core-hub, and the counted isolation probe. Each workload declaration reserves 12 runtime plus two migration connections; the probe's smaller allowance is deliberately overstated here, making 56 a conservative declared-pool occupancy.

Method

A temporary namespace labeled as a platform-pg client received the existing bootstrap Secret by namespace-to-namespace projection without printing its values. A separate client pod opened 56 sessions in four named groups of 14. This kept client-process memory outside the database pod. The run then repeated the same 56-session occupancy with 13 idle and one bounded active sort query per group. The namespace and copied Secret were deleted after the run.

The active query materialized and sorted 100,000 generated integers, then held the backend briefly for observation. It did not access an application table.

Observations

Signal	Before	Declared occupancy / observed peak
Probe sessions	0	56 (14 in each named group)
All PostgreSQL sessions	9	65
Active / idle sessions	1 / 2	5 / 54 in the mixed run
PostgreSQL pod memory	89Mi	174Mi maximum observed
PostgreSQL pod CPU	7m	82m during connection startup
Node memory	6,210Mi / 16Gi	6,342Mi / 16Gi (39%)
Node CPU	470m	2,002m transient startup peak

The 85Mi database-pod increase across 56 opened backends is approximately 1.52Mi per connection at declared pool occupancy. That replaces ADR-0004's unmeasured 10Mi literature estimate for idle/backend occupancy on this live instance; it does not claim every query operator is limited to that figure.

The earlier quiet preflight observed 362Mi. Conservatively adding the entire measured connection delta to that higher historical sample gives 447Mi, under 44% of the 1Gi limit. The four bounded active queries did not exceed the 174Mi maximum already observed during connection startup.

Decision

Core Hub is accepted as the fourth declaration on platform-pg without a memory-limit increase. It reaches the declared ceiling and does not authorize a fifth declaration. The renderer must continue to reject any additional consumer on this cell; the named overflow remains platform-pg-2.

This is capacity admission evidence, not a latency or workload-peak guarantee. Core Hub is latency-critical beside batch audit-core, and community PostgreSQL provides no service-class priority. The private shadow run must therefore capture application health, query latency, pod memory, and backend counts; material regression is a placement trigger, not a reason to reinterpret this probe as stronger evidence.