# 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.