Is Supabase HIPAA Compliant? Yes — Here’s What the BAA Actually Requires (2026)

Yes — Supabase is the rare tool in this series where the answer is genuinely “yes,” not “no” or “it depends.” Supabase’s hosted platform is SOC 2 Type II certified, ISO 27001 certified, and offers a signed Business Associate Agreement (BAA) as a paid HIPAA add-on to Team ($599/month) and Enterprise customers. But “yes” comes with real conditions: the HIPAA add-on isn’t available on Free or Pro plans, self-hosted Supabase gets none of this out of the box, and signing the BAA is only the starting point — you’re still responsible for marking projects as HIPAA-compliant, enforcing MFA, enabling Point-in-Time Recovery, turning on SSL enforcement and network restrictions, and keeping connection logging on. Skip any of those, and the BAA on file doesn’t help you.

---

Building a healthcare app on Supabase and need to confirm your whole stack is compliant? HIPAA Vault reviews everything Supabase doesn’t cover — the application layer, the frontend, and beyond — remediates the gaps, and deploys the BAA-covered environment your stack is missing.

Book a Free 15-Minute Consultation →

---

Key Takeaways

• Supabase’s hosted platform is genuinely HIPAA compliant: SOC 2 Type II certified, ISO 27001 certified, and a signed BAA is available as a paid add-on — a real, executable agreement, not “we’ll entertain it.”
• The HIPAA add-on requires the Team plan ($599/month minimum) or Enterprise. Free and Pro plans get no SOC 2, no ISO 27001, and no HIPAA add-on at all.
• Self-hosted Supabase does not get HIPAA support out of the box. Supabase’s own documentation states plainly: “These controls are not supported out of the box in self-hosted Supabase.”
• Signing the BAA doesn’t finish the job. Customers must mark projects “High Compliance,” enforce MFA across the organization, enable Point-in-Time Recovery (its own paid compute add-on), turn on SSL enforcement, apply network restrictions, and keep Postgres connection logging enabled for audit trails.
• Supabase draws a hard line between its own SOC 2/HIPAA coverage and everything a developer builds on top of it: your application architecture, access management, Row Level Security policies, and any third-party integrations remain entirely your responsibility under Supabase’s shared responsibility model.
• Supabase is commonly paired as the backend for vibe-coding frontend tools like Bolt.new, Lovable, and v0 — none of which offer a BAA themselves. Using a HIPAA-compliant Supabase backend does not make a non-compliant frontend tool compliant; each layer of the stack needs its own answer.

---

Does Using Supabase Involve PHI?

Unlike the AI coding assistants examined elsewhere in this series, Supabase isn’t a place PHI might accidentally show up — it’s often the database explicitly built to hold it. Supabase is Postgres-as-a-service plus authentication, storage, realtime, and edge functions, which means PHI risk isn’t a side effect of using the tool; it’s the entire point for a healthcare application. That reframes the question: it’s not “could PHI end up here,” it’s “have you actually configured this the way HIPAA requires, and did you sign the agreement that makes doing so legally meaningful.”

Real PHI enters a Supabase project through:

• Database rows — patient records, appointment data, clinical notes stored directly in Postgres tables.
• Storage buckets — uploaded documents, images, or files that may contain PHI (Supabase explicitly warns against storing PHI in public storage buckets).
• Auth records — user accounts tied to real patients, including email addresses and any custom user metadata.
• Realtime and Edge Function payloads — data flowing through live subscriptions or serverless functions that touch the same underlying tables.
• Third-party integrations — OAuth providers, SMTP/SMS senders, or external API calls a developer wires up themselves, which fall outside Supabase’s compliance boundary entirely.

If your project handles any of the above and you haven’t signed a BAA with Supabase and enabled the HIPAA add-on, you’re out of compliance the moment real patient data enters the database — regardless of how the frontend was built.

---

Supabase’s Security Posture vs. What HIPAA Requires

Verified against security, hipaa compliance, shared responsibility model, hipaa projects, and pricing, all confirmed July 22, 2026. Vendor terms and pricing change — confirm current BAA availability and cost directly with Supabase before relying on this for a live HIPAA program.

---

What the HIPAA Add-On Actually Requires You to Do

Getting Supabase’s BAA signed is the beginning of the compliance work, not the end. Supabase’s shared responsibility model lists the customer’s obligations explicitly once the HIPAA add-on is enabled:

1. Sign the BAA. Submit a HIPAA add-on request through Supabase’s form — this requires at least the Team plan.
2. Mark specific projects as “High Compliance.” This is done per-project in the dashboard, not automatically applied account-wide.
3. Enable and enforce Multi-Factor Authentication across every Supabase account with access to the organization — not just recommended, but a stated requirement.
4. Enable Point-in-Time Recovery, which itself requires at least a small compute add-on — an additional cost stacked on top of the Team plan’s $599/month.
5. Turn on SSL Enforcement and Network Restrictions to control how the database can be reached.
6. Keep Postgres connection logging enabled. Supabase disables log_connections by default for new projects; HIPAA projects need it left on for audit trails, and the Security Advisor will flag it if disabled.
7. Encrypt appropriately. Supabase encrypts data at rest and in transit by default, but the guidance explicitly suggests considering application-layer encryption as an additional measure.
8. Never store PHI in public Storage buckets.
9. Never transfer a HIPAA-designated project to a non-HIPAA organization.

Supabase’s Security Advisor continuously checks for configuration drift on these controls and issues warnings — but applying the fix remains the customer’s job. A signed BAA sitting alongside a misconfigured project (MFA not enforced, connection logging quietly disabled, a storage bucket accidentally made public) does not equal HIPAA compliance in practice.

---

Two Technical Traps That Sit Outside Supabase’s BAA — Inside Your Row Level Security Policies

Supabase’s BAA covers the platform. It does not review the Row Level Security (RLS) policies, queries, or authorization logic your AI coding tool writes against that platform — and that’s exactly where the two most common vibe-coding mistakes show up. In a HIPAA Vault livestream Q&A, Joshua Vidals, HIPAA Vault’s cloud engineer, described both in concrete terms.

The first is unsanitized input reaching the database directly:

“If you have a search box on your application that’s going through your database and looking for patient records, and your code doesn’t sanitize what the user types in that box before it goes to the database, a hacker could issue a command through that search box — they could drop all the tables, delete the database. They can also pull patient records, and a breach is what you want to avoid at all costs.”

The second is the difference between authentication and authorization — confirming who someone is versus confirming what they’re allowed to see:

“The best way I could put this is: if you have your AI that’s vibe coding create you an automated bouncer for a bar, and you program it to look at the ID, look at the age, and determine if that user can be let in based on their age — but you forgot to prompt the AI to also check the photo to make sure it’s the correct person. So people line up at the door, your bouncer looks at the age, verified, come on in. Now the user’s in your application, say they have in the URL bar ‘patient record 101,’ and they’re authenticated to see that. But if they erase that URL and put in ‘record 102,’ and suddenly they’re looking at somebody else’s records they’re not authorized to see — you forgot to bake in the authorization, as well as the permissions that allow them to get in.”

Both traps map directly onto Supabase-specific settings: the first is a parameterized-query and input-validation problem in whatever code your AI tool generates against Postgres; the second is precisely what Row Level Security policies exist to prevent — a policy scoped only to “is this user logged in” instead of “does this user own this specific row” leaves every record reachable by guessing or incrementing an ID, exactly like the record 101/102 example above. Supabase’s BAA and certifications don’t check whether your RLS policies actually enforce row-level ownership; that verification is on you, and it’s worth treating as its own line item on top of the Security Advisor checklist above.

---

Which Plan Do You Actually Need?

Plan	Price	SOC 2 / ISO 27001	HIPAA add-on available
Free	$0/month	❌ Not included	❌ Not available
Pro	From $25/month	❌ Not included	❌ Not available
Team	From $599/month	✅ Included	✅ Available as paid add-on
Enterprise	Custom	✅ Included	✅ Available as paid add-on

A healthcare team prototyping on Supabase’s Free or Pro plan is, by definition, not in a position to sign a BAA yet — SOC 2, ISO 27001, and HIPAA are all gated behind the Team plan’s $599/month floor, before accounting for the additional compute add-on Point-in-Time Recovery requires. This matters for planning: a vibe-coded healthcare MVP that starts on Supabase’s Free tier to move fast will need a deliberate upgrade — plan tier, HIPAA add-on request, and project reconfiguration — before any real patient data can legally touch it.

---

The Self-Hosted Trap

Supabase is open source, and self-hosting is a popular option for teams that want full infrastructure control. For HIPAA purposes, this is a meaningful trap: Supabase’s own documentation states directly that “the hosted Supabase platform has the necessary controls to meet HIPAA requirements. These controls are not supported out of the box in self-hosted Supabase,” and that achieving HIPAA compliance on a self-hosted deployment is “out of scope” for Supabase’s own guidance — customers pursuing that path are told to consult their own auditor.

In practice, this means the entire “yes” answer in this article applies specifically to Supabase’s hosted platform on a Team or Enterprise plan with the HIPAA add-on enabled. Self-hosting removes the BAA, the SOC 2/ISO 27001 coverage, and the pre-built HIPAA project controls — you’d be rebuilding all of it yourself, with no vendor agreement backing it.

---

What Gil Vidals Says About Vibe Coding Platforms and HIPAA

Supabase wasn’t one of the four platforms Gil Vidals named directly on the HIPAA Insider Show — that list was Cursor, Replit, Bolt.new, and v0, all frontend-facing app builders. Supabase sits in a different position in the stack: it’s the backend database layer those tools frequently connect to. That distinction actually reinforces Gil’s core point rather than complicating it:

“I don’t believe these building platforms offer HIPAA compliance. I don’t think that’s their forte.”

Gil’s broader argument is that compliance has to happen at the infrastructure layer, not inside the tool that generates code:

“At this juncture, AI is trapped in the virtual world. It does everything inside the computer — it’s digital. To be HIPAA compliant, you have to touch the physical world. The AI doesn’t do that yet. That means you have to have infrastructure that’s HIPAA compliant… and even if that infrastructure is configured, the code itself is probably going to live on a virtual machine, and that virtual machine has to be configured to be HIPAA compliant too. You have to monitor it, scan it, run vulnerability reports, patch it on a weekly or monthly basis.”

(Source: HIPAA Insider Show, Episode 107, “Vibe Coding to HIPAA-Compliant Production: The Steps.“) Supabase is a genuine example of that infrastructure layer done right — a signed BAA, real certifications, and documented controls. But it’s still only the database layer. A vibe-coded frontend built in a tool with no BAA, deployed with a Supabase backend that does have one, is not automatically a compliant application — every layer needs its own answer, and Supabase answering “yes” doesn’t let the rest of the stack off the hook.

---

Turning On HIPAA Compliance on Supabase: The Actual Steps

1. Confirm you’re on the Team plan or above. If you’re prototyping on Free or Pro, budget for the upgrade before any real PHI enters the picture.
2. Submit the HIPAA add-on request through Supabase’s form and get the BAA signed before any patient data is stored — not after.
3. Mark every relevant project as “High Compliance” in the dashboard, not just the primary production project.
4. Work through the Security Advisor’s HIPAA checklist: enforce org-wide MFA, enable Point-in-Time Recovery (budgeting for the compute add-on it requires), turn on SSL enforcement and network restrictions, and confirm connection logging is active.
5. Audit your Storage buckets to confirm none holding PHI are public.
6. Review everything outside Supabase’s boundary — your application code, your frontend tool (if it’s Bolt.new, Lovable, v0, or similar), your third-party integrations, and any data exported or cached outside Supabase. None of that is covered by Supabase’s BAA.
7. Re-verify before every major change. Project transfers to non-HIPAA organizations, new third-party integrations, or a public storage bucket added during a feature sprint can silently break compliance that was correctly configured months earlier.

---

Your Backend Is Only One Layer — Even a Compliant One

Supabase getting HIPAA right at the platform level is a genuinely different story from every AI coding tool examined elsewhere in this series — a real BAA, real certifications, and detailed, specific customer guidance rather than silence on the topic. But Supabase’s own shared responsibility model is explicit about where its responsibility ends: application architecture, access management, database schema decisions, and third-party integrations are yours to secure, regardless of what Supabase covers underneath. As Gil Vidals puts it, HIPAA compliance “is not a one and done” — a signed BAA with your database provider is one necessary layer, not the whole stack.

HIPAA Vault has provided that full-stack infrastructure layer since 1997, with certifications including NIST 800-53, SOC 2 (AICPA), HITECH Omnibus, and GSA. Whether your backend is Supabase or something else, the application layer running on top of it still needs its own compliant, BAA-covered home.

Need help making sure every layer of your Supabase-backed app is actually compliant? HIPAA Vault reviews the layers outside Supabase’s compliance boundary, remediates the gaps, and deploys you to a BAA-covered environment.

Book a Free 15-Minute Consultation →  |  Talk to a specialist →

---

Questions to Ask Before Storing PHI in Supabase

1. Have you actually signed the BAA and enabled the HIPAA add-on, or are you assuming Supabase’s general SOC 2 marketing covers PHI? It doesn’t — SOC 2 and HIPAA are explicitly separate at Supabase.
2. Are you on the Team plan or above? Free and Pro users cannot get a BAA at all, regardless of how the project is configured.
3. Have every one of the Security Advisor’s HIPAA checks been resolved — MFA enforcement, Point-in-Time Recovery, SSL enforcement, network restrictions, and connection logging?
4. Is any Storage bucket holding PHI accidentally set to public?
5. What’s actually happening outside Supabase? Your frontend tool, any third-party integrations, and your application code all sit outside Supabase’s BAA coverage and need their own compliance answer.
6. Are you self-hosting? If so, none of Supabase’s HIPAA coverage applies, and you’re rebuilding these controls and agreements entirely on your own.
7. Do your Row Level Security policies actually scope access to “this user owns this row,” or only to “this user is logged in”? The second version leaves every record reachable by anyone who can guess or increment an ID — the exact authorization gap AI-generated code tends to leave open.

---

Frequently Asked Questions

---

Educational content, not legal advice — consult a qualified HIPAA compliance attorney for your organization. Vendor terms reflect Supabase’s published policies as of July 2026; verify current BAA availability, plan requirements, and add-on pricing before relying on this for a live program.