Permission and role documentation for managed database teams

When a team is told 'permission setup is a bit difficult when you want to access the database manually' and 'data control and user with independent permission' is flagged as a limitation, the underlying problem isn't that permissions are hard to set — it's that managed databases strip out the OS-level and superuser-level visibility that DBAs use to audit and document who can do what. In a self-managed database, a DBA can query system tables freely, script out all roles, and know exactly what a given user can and can't do. In RDS or Aurora, restricted access to the master database and no superuser means those same queries are either blocked or return incomplete results.

The gap persists structurally because cloud providers expose permissions through their own IAM and database-native roles simultaneously — two separate systems that don't talk to each other — and neither surface makes it easy to answer 'what can this application user actually do right now?' The people who care most about this are security engineers and compliance auditors, who are typically not the same people who provisioned the database and often don't have direct database access themselves.

Right now, teams handle this by keeping manual spreadsheets, running ad-hoc `\du` and `information_schema.role_table_grants` queries and pasting results into Confluence, or simply not having documentation until an audit forces the question. None of this captures the interaction between cloud IAM permissions and database-level roles, and none of it stays current. The cost of the gap is real: a misconfigured permission causes an incident, or an auditor flags undocumented access, and the DBA spends days reconstructing what should have been a live report.

This is a business because the need recurs every time a new engineer joins, every time an application credential rotates, every time a compliance review happens, and every time a managed service version upgrade potentially resets role configurations. The buyer — a security-conscious engineering lead or a compliance-driven DBA — has a budget line for access control tools and a concrete event (SOC 2 audit, PCI review) that forces them to pay.

What to build

Build a scheduled connector that queries accessible permission and role tables on managed PostgreSQL, RDS, and Aurora instances, merges that data with cloud IAM role bindings for the same databases, and generates a continuously-updated human-readable access map showing exactly what each database user and application credential can do — with change history and an exportable audit report.

Where to start

Start with companies actively going through SOC 2 Type II certification who need documented evidence of least-privilege database access — they have a hard deadline, a budget, and a concrete deliverable the tool produces, which makes the first sale a compliance project rather than a discretionary purchase.

The hard part

Merging cloud IAM permissions with database-native roles requires AWS API access in addition to database credentials, which means the buyer needs to grant two separate authentication scopes — that's a sales and onboarding friction point that will kill early trials if the setup isn't nearly zero-config.

How it makes money

Annual subscription per database cluster, priced to sit below the cost of a DBA's time to manually reconstruct the same documentation for a single audit cycle.