Topic starter
11/06/2026 11:09 pm
TL;DR: Session storage and directory sync need simpler operational patterns than Postgres can always deliver at scale, according to Pomerium. The deeper lesson is that identity enforcement depends on durable, quickly recoverable state, not just a familiar database choice.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Sometimes Postgres isn’t the Answer”.
Key questions
Q: What breaks when identity is treated as a login layer only?
A: When identity is treated as a login layer only, teams miss the fact that many high-risk decisions happen after authentication, inside delegated workflows and tool chains.
Q: When does Postgres become the wrong choice for access-proxy state?
A: Postgres becomes a poor fit when the real problem is not data storage alone but low-latency replication, simple recoverability, and easy day-two operations at scale.
Q: How can teams tell whether authorization state is actually recoverable?
A: A useful test is whether sessions and directory context can be rebuilt quickly after a restart without manual repair.
Practitioner guidance
- Audit identity-state dependencies Map which authorization decisions depend on session data, directory sync, and external context that must remain current between logins.
- Separate recomputable context from authoritative state Classify which access inputs can be rebuilt after restart and which ones must remain continuously durable for policy enforcement.
- Measure state replication latency Test how quickly a membership change, session update, or policy-relevant record reaches every proxy or databroker instance.
Bottom line: Identity-aware access proxies can lose policy fidelity when session and directory state are tied to storage patterns that do not match real operational load.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
12/06/2026 7:41 am
Identity enforcement fails when policy state is treated like ordinary application data. This article shows that access decisions depend on state freshness, recoverability, and operational accessibility, not simply on choosing a familiar database. When directory data changes faster than the storage pattern can absorb, authorization drifts away from the identity source of truth. Practitioners should treat state design as part of the access-control model, not just platform plumbing.
A question worth separating out:
Q: Should IAM teams centralize all policy data in one datastore?
A: Not always. Centralization only helps when the datastore can sustain the read-write pattern, replication needs, and operational support model of the access system. For some identity workloads, simpler local persistence with controlled clustering is easier to govern than a shared database that becomes the bottleneck.
👉 Read our full editorial: Pomerium’s Databroker shift shows why Postgres is not always enough
This post was modified 18 hours ago by NHI Mgmt Group