Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Databroker storage and Raft clustering: what IAM teams should notice


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 5324
Topic starter  

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.

NHIMG editorial — based on content published by Pomerium: Sometimes Postgres isn’t the Answer

Questions worth separating out

Q: How should teams decide whether identity state belongs in Postgres or a simpler backend?

A: Teams should choose the backend that best matches the identity state they must preserve, the recovery time they can tolerate, and the operational skills they actually have.

Q: Why do directory sync and session storage need to be separated in access control systems?

A: Directory data changes independently of login events, so waiting for the next sign-in delays revocation and can leave access valid longer than intended.

Q: What breaks when access context lives only in browser cookies?

A: Central visibility disappears, revocation becomes harder to enforce, and large or changing claims can exceed cookie limits or go stale between logins.

Practitioner guidance

  • Map identity-state dependencies before changing storage Inventory which access decisions depend on session cookies, directory sync, and external context so you can see where state loss becomes an authorization event.
  • Test revocation latency under backend failure Measure how quickly group removal, session invalidation, and directory updates propagate when the primary Databroker node is unavailable or recovering.
  • Set explicit recovery objectives for identity context Document whether the system must preserve every session, restore most sessions, or simply rehydrate state fast enough to avoid material access disruption.

What's in the full article

Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:

  • The Databroker data model, including keyspaces, record types, and how sorted storage supports lookups and change streams.
  • The operational reasoning behind Pebble selection over SQLite, bbolt, and badger for local persistence.
  • The Raft leader-election design, including why the team chose not to replicate the full state machine.
  • The practical configuration example for enabling file-based Databroker storage in v0.31.

👉 Read Pomerium's post on why the Databroker moved beyond Postgres →

Databroker storage and Raft clustering: what IAM teams should notice?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
Share: