HIPAA · Database and backend
Is Supabase HIPAA compliant?
Conditional
Supabase will sign a BAA, and has BAAs in place with its own vendors. Coverage is not automatic: projects that hold PHI must be configured as HIPAA projects and follow the security advisor's guidance.
- Which plans the BAA covers
- Available to customers who sign Supabase's BAA. Supabase states it has signed BAAs with all of its own vendors.
Scope
What the BAA does and does not cover.
Covered
- Supabase projects explicitly configured as HIPAA projects, used within the responsibilities the BAA sets out
Not covered
- Projects not configured as HIPAA projects
- Anything falling outside the customer responsibilities the BAA assigns to you
Your side of the agreement
A signed BAA is not a configured system.
Signing shifts liability; it does not change a setting. These are the steps that remain yours once Supabase is in scope.
- 1Sign the BAA, then mark the relevant projects as HIPAA projects — signing alone does not configure anything
- 2Work through the security advisor warnings; they are the documented baseline, not suggestions
- 3Enforce row-level security on every table that can hold PHI
- 4Restrict and review who holds service-role keys and direct database access
Evidence
What an auditor will actually ask for.
Every item below is evidence someone has to produce, date and re-produce at the next audit. Screenata's agent collects these on a schedule instead.
- The signed BAA
- Project settings showing HIPAA mode enabled for each PHI-bearing project
- A clean security advisor report, or documented exceptions with rationale
- RLS policy definitions for PHI tables, plus access reviews for service-role key holders
See how Screenata handles this on HIPAA programs, or read what healthcare SaaS needs beyond SOC 2.
Sources
Verified against vendor documentation on 2026-08-08. BAA terms change — re-check before relying on this.