A founder once asked Supabase’s own AI assistant whether he could get HIPAA coverage on the Pro plan. It told him yes, as a $200 per month add-on. He took that into a GitHub discussion, where a Supabase collaborator replied that it was inaccurate and that “AI’s are notorious for making stuff up.” That thread is still on the first page for this question as of 2026-07-29, wrong answer and misspelled title included.
Supabase is HIPAA compliant as a platform, on Team or Enterprise, once a Business Associate Agreement (BAA) is signed and the paid add-on is enabled. That is the half the search results answer well. The other half decides whether patient data stays where it belongs, and it lives in your application code. Of the 21 third-party apps in the AxonBuild audit corpus, reviewed June and July 2026, three handled real clinical data. They scored 29, 36 and 48 out of 100, all red, and every one of those failures sat in a layer no BAA, add-on or SOC 2 report reaches.
Is Supabase HIPAA compliant on the Team plan or the Pro plan in 2026?
Supabase is HIPAA compliant at the platform layer on Team and Enterprise only, with a signed BAA and the paid HIPAA add-on enabled, which starts at $350 a month. Free and Pro have no BAA path at any spend, so a health app on either sits outside the compliance boundary before a line of its code is read.
HIPAA has no certifying body and issues no certificates, so nobody is HIPAA certified, Supabase included. Supabase holds a signed contract and an audited control set. Its security documentation calls that arrangement a shared responsibility model, under which Supabase is “directly liable for compliance with certain provisions of the HIPAA Rules” and you carry everything else.
What does the Supabase HIPAA add-on cost per month on the Team plan?
The Supabase HIPAA add-on starts at $350 a month and attaches only to Team or Enterprise. Team itself starts at $599 a month, putting the compliance floor at roughly $949 before compute, storage or Point in Time Recovery, and no page on supabase.com states that total in one place.
| Plan | Can Supabase sign a BAA? | SOC 2 and ISO 27001 | HIPAA add-on |
|---|---|---|---|
| Free | No | Not included | Not included |
| Pro | No | Not included | Not included |
| Team (from $599/mo) | Yes | Included | Available as paid add-on, from $350/mo |
| Enterprise | Yes | Included | Available as paid add-on, priced on contact |
Supabase’s pricing page carries the availability without the figure: the HIPAA row reads “Available as paid add-on” on Team and Enterprise and “Not included” on Free and Pro, with no dollar amount anywhere. The $350 comes from the marked answer in GitHub discussion 35594, posted by Supabase maintainer mansueli in August 2025: “HIPAA pricing for Supabase starts at $350 per month as an add-on to the Teams or Enterprise plans. Not available on Pro or Free plans.” The shared responsibility model puts the floor in its own words: “You will need to be at least on the Team Plan to sign a BAA with us.”
Founders meet this in the wrong order. You build on Pro at $25 a month, land a customer who asks for a BAA, and find the answer is a plan migration and a bill roughly thirty-eight times what you were paying.
What must you configure yourself to store PHI on Supabase under a signed BAA?
Four project settings are mandatory before a Supabase project counts as compliant, and signing the BAA turns on none of them. The BAA and the add-on are step one; marking the project High Compliance in its General Project Settings is step two, and these four are what that marking enforces.
- 01 Point in Time Recovery, which needs at least the Small compute add-on beneath it to keep continuous archiving from falling behind. On the pricing page it runs $100 a month for seven days of retention, before that compute
- 02 SSL enforcement, so the database refuses unencrypted connections instead of merely offering encrypted ones
- 03 Network restrictions, limiting which addresses can reach the database at all rather than leaving it open to any caller holding a key
- 04 Postgres connection logging kept on, so there is a record of who connected and when
The HIPAA projects guide says these checks run “on a continual basis and security warnings will appear in the Security Advisor if a non-compliant setting is detected,” so a setting someone switches off six months from now gets flagged rather than sitting there unnoticed. Price the first one before committing, because what Point in Time Recovery actually costs on Supabase lands well above its headline add-on line. The shared responsibility document adds two duties no settings page enforces: keep MFA on across the organization, and never put PHI in a public Storage bucket.
Where does Supabase HIPAA compliance stop covering your app?
Supabase HIPAA compliance covers the platform Supabase runs and stops at the schema you wrote. Encryption at rest, physical access, patching and audited operational controls are Supabase’s. Which rows a logged-in user can read is yours, and that is the side where all three health apps in my corpus failed.
One line in the shared responsibility model is easy to read past. After confirming that Supabase encrypts data at rest and in transit, it adds: “You can consider encrypting the data at your application layer.” The entire application half of HIPAA, offered as a suggestion. Neither the HIPAA compliance guide nor the HIPAA projects guide names row-level security at all, so a founder reading both end to end finds nothing telling them the query layer is still theirs. The platform half gets its own answer in whether Supabase is safe as a platform or as you configured it.
A BAA moves liability. It does not move a plaintext column.
What actually breaks HIPAA in a health app built with AI tools?
Three of the 21 third-party apps in my corpus stored real clinical data, and all three came out red: 29, 36 and 48 out of 100. Every finding that would have mattered to a regulator sat in application code, the layer that looks the same whether the app came out of Lovable, Bolt, Base44, v0 or Claude Code.
One caveat that changes what those numbers prove: none of the three ran on Supabase. One was self-hosted Postgres, one Neon behind Next.js, one Flask with SQLAlchemy. Read them as evidence about Supabase health apps specifically and you would be reading them wrong. Across all three, on three different stacks, the damage sat above the database, in the layer no add-on and no BAA reaches.
The 29 was a medical-advice app. Medical history, allergies, medications, every vital and lab result, insurance policy numbers and dates of birth, all in Postgres columns with no column-level or application-level encryption. Grepping the repository for pgcrypto or any cipher library returned bcrypt on the password field and nothing else, which is the detail that stayed with me: someone had thought hard about the passwords and never once about the medical record behind them.
The 36 was a multi-tenant health API that chose whose data to return from a client-supplied X-Tenant-Id header. The switch that would have authenticated that claim shipped off, and no deploy config turned it on. A stranger with no account could name a tenant and get diagnoses, lab values, medications and allergies in bulk, through a redaction layer that kept clinical codes, birth year, city and the last four digits of identifiers.
Then the 48, a FHIR community hub built for clinicians, where the clinical discussion boards had no login check on the write path at all, so a stranger could post and edit entries clinicians read as reference.
The third row has no configuration screen behind it. That same medical-advice app posted the full clinical payload, demographics and labs together, to a hosted LLM with no de-identification and no BAA or DPA in the repository. Your database can sit inside a perfectly compliant boundary while one fetch call carries the record out of it. Row-level security does not close that path; nothing inside the database can.
Every finding there was verified against the code, not pattern-matched, and the full corpus numbers behind what 26 audits of AI-built apps actually found carry their denominators with them.
What are the HIPAA compliant alternatives to Supabase for patient data?
The HIPAA compliant alternatives to Supabase are the names you would guess: all three major clouds sign BAAs, AWS, Google Cloud and Azure, and so do Neon and the health-specific platforms that wrap more operational work around the database. Picking a HIPAA compliant database is the easy half of this decision. Every one of those vendors draws the line in the same place Supabase does, and your authorization logic sits on your side of it.
That is worth knowing before anyone migrates. Moving to AWS for HIPAA reasons fixes the plan tier and the contract, and carries the tenant-from-header bug across untouched. Migrate for pricing, a region, or something Supabase genuinely does not do, and run the Supabase alternatives comparison on what you own after the switch rather than on the feature grid.
A pre-launch check if your app already stores health data
Four checks tell you whether a plan upgrade would make your app compliant or only more expensive, and none needs a security background. Run them before buying anything, because what they turn up changes what you are buying.
- 01 Find every column holding PHI: names, dates of birth, diagnoses, medications, insurance identifiers, free-text notes. The compliance conversation is about that list and nothing else
- 02 Create a second account and try to read the first account's records through the normal interface, changing only an id. If that works, no plan tier fixes it
- 03 List every third party the clinical data reaches: model provider, analytics, error tracker, email service. Each needs its own BAA, and the error tracker is the one people forget
- 04 Search your logs for patient data. Debug logging that prints a request body is the most common way PHI leaves a compliant database
Whatever those four turn up is the real scope of the work, and it is the same scope on Pro at $25 as on Team with a signed BAA. Once you have that list, what a launch-readiness audit looks for in an app that touches patient data is more use than another plan comparison, and the wider version of the same question is whether your AI-built app is ready to launch.
Common questions about Supabase and HIPAA
Is Supabase SOC2 and HIPAA compliant?
Supabase is SOC 2 Type 2 compliant as a platform, and HIPAA compliant on Team and Enterprise with a signed BAA and the paid add-on enabled. The two are separate: SOC 2 covers Supabase’s own operational controls, while HIPAA coverage needs the contract and the add-on on top. The platform-versus-app split behind both is identical.
Can I use the Supabase free tier for a HIPAA app?
No. Neither Free nor Pro has a BAA path, so no amount of configuration on either one puts a health app inside the compliance boundary. A BAA requires Team or Enterprise plus the HIPAA add-on, which starts at $350 a month on top of the plan.
Does signing a BAA make my app HIPAA compliant?
No. A BAA makes Supabase a business associate with defined legal duties for the infrastructure it runs, and leaves your application to you. All three health apps in the AxonBuild corpus would still have exposed patient data with a signed BAA in place, because their failures were in query logic and header handling.
Are Supabase Edge Functions covered by the BAA?
Confirm the scope with Supabase directly, because the public documentation does not answer it. As of 2026-07-29 the HIPAA compliance guide, the HIPAA projects guide and the shared responsibility model mention Edge Functions in neither direction, and the only product-level exclusion any of them states concerns PHI in public Storage buckets. Some search summaries claim Supabase advises against processing PHI in Edge Functions; I could not find that advice in any primary source.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
