Database Infrastructure for Managed Security Providers

AWS RDS runs natively inside a VPC you control, with security groups and network ACLs restricting access at the network layer before any application-level control is even checked. For an MSSP storing client security event data, that network-layer isolation is often a contractual requirement, not a preference. Supabase can restrict database access to specific IP ranges and enforces row-level security at the application layer, which covers most access-control needs, but it does not give you the same private VPC peering into other AWS-hosted client infrastructure that RDS does natively.

Read your own client contracts closely before assuming this decision has already been made for you. Some MSSP agreements name network isolation explicitly; others describe an outcome (data cannot leave a defined boundary) without naming the mechanism, which leaves you more room to choose whichever platform fits the rest of your stack.

When an MSSP's own security posture gets audited, alongside the client environments it monitors, reviewers ask for evidence of who accessed what data and when. AWS RDS's integration with CloudTrail and IAM can produce access and change evidence in a format many SOC 2 auditors are familiar with, though database-level activity usually needs additional audit logging. Supabase logs access at the platform level and Postgres's own row-level security policies define exactly what each role can see, which is defensible in an audit but requires you to document the mapping yourself rather than pulling it from a familiar AWS-native log format. Build that documentation once, keep it current as policies change, and treat it as part of your own audit preparation rather than something you assemble the week the auditor asks for it.

Security event data accumulates quickly, and an MSSP monitoring several clients can see database growth that outpaces a typical SaaS application. RDS's granular storage billing (you pay for what you provision, and can grow it incrementally) and support for read replicas make it straightforward to separate high-volume writes (incoming events) from the dashboards and reports clients read. Supabase handles this too, but its flat-tier pricing model means a sudden spike in event volume is more likely to push you into a higher tier than to show up as a proportional line-item increase.

An MSSP's dashboard being down during an active incident is its own kind of failure. A 99.95% uptime target allows roughly four and a half hours of downtime a year¹; build your monitoring alerts around that budget specifically, not a generic uptime number, and test failover on a schedule rather than assuming multi-AZ replication will behave the way its description implies during an actual event.

An MSSP's own database is a single point of failure for every client it protects, which makes tenant isolation between clients its own security requirement, not just a data-modeling choice. Row-level security policies keyed to a client identifier keep one client's analysts from ever seeing another client's events through the application layer, on either platform, since it is a property of PostgreSQL itself, not something either vendor adds on top.

Where the platforms differ is in defense against a compromised application server rather than a misbehaving query. RDS's network-layer isolation means a compromised application instance in one client's environment still cannot reach the database directly unless its security group explicitly allows it; that additional layer is worth the setup effort for an MSSP specifically, since your own infrastructure is a higher-value target than most of the applications you monitor.

• Confirm whether client contracts require network-layer isolation (VPC peering) specifically, not just application-level access control
• Map out which audit log format your compliance framework expects, and check that your chosen platform can produce it
• Plan for event data growth explicitly; storage volume for an MSSP rarely grows linearly
• Test failover under simulated load, not just in a quiet maintenance window, since that is closer to the conditions of a real incident
• Key every row-level security policy to a client identifier so tenant isolation holds even as new client environments are added