TL;DR: PlanetScale’s move into Postgres support highlights a broader shift toward developer-friendly databases, but it also underscores how extensions, operational complexity, and fast-scaling AI workloads expand the secret and access risk surface, according to WorkOS’s interview with Sam Lambert. The security lesson is that convenience and flexibility do not remove governance debt; they redistribute it across identity, configuration, and lifecycle control.
NHIMG editorial — based on content published by WorkOS: PlanetScale is riding the Postgres wave while still loving MySQL
By the numbers:
- AI companies are adding 25 terabytes of data per week per cluster.
Questions worth separating out
Q: How should teams govern Postgres extensions in production databases?
A: Treat Postgres extensions as privileged code that expands the trusted boundary of the database.
Q: Why do hosted databases still create identity and access risk?
A: Hosted databases reduce operational burden, but they do not remove the need to govern who can administer, automate, and modify them.
Q: What do security teams get wrong about database scaling?
A: They often focus on performance and availability while underestimating how fast credentials, integrations, and administrative exceptions multiply.
Practitioner guidance
- Review database extension trust boundaries Inventory which Postgres extensions are allowed in production, who approves them, and whether any require elevated database privileges.
- Map database access to named owners Assign a clear business and technical owner to every database administrator account, service account, and automation credential.
- Track AI workload growth against secret sprawl As cluster data volume rises, review whether database credentials, integration tokens, and automation secrets are multiplying faster than the team can review them.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Sam Lambert’s broader reasoning on why Postgres is winning despite operational tradeoffs.
- The practical discussion of trusted Postgres extensions and why providers validate a limited set.
- The economics behind PlanetScale’s $5 tier and how engineers actually choose database plans.
- The AI workload context behind the 25 terabytes per week figure and its infrastructure implications.
👉 Read WorkOS’s interview on PlanetScale’s Postgres strategy and AI-scale database growth →
PlanetScale and Postgres: what changes for IAM and secrets teams?
Explore further
Database convenience now shifts the governance burden, it does not remove it. Hosted database platforms reduce operational friction, but they also centralise trust in extension curation, access administration, and managed control planes. That means identity teams inherit a broader boundary to govern, especially where service accounts and automation depend on persistent database entitlements. The practitioner conclusion is that platform simplicity must be matched with stricter ownership and access clarity.
A few things that frame the scale:
- AI companies are adding 25 terabytes of data per week per cluster, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: When should organisations re-evaluate database access controls for AI workloads?
A: Re-evaluate them whenever the workload begins ingesting data at a rate that changes how quickly access is provisioned and forgotten. AI clusters tend to increase integration count, automation depth, and secret volume at the same time. That is when static review cadences stop reflecting reality.
👉 Read our full editorial: PlanetScale's Postgres move shows where database identity risk shifts