Is Supabase HIPAA Compliant? What the BAA Covers and What It Doesn't

Short answer: Supabase supports HIPAA workloads, but only on Team or Enterprise, with a signed BAA, the paid HIPAA add-on, and the covered projects marked High Compliance. Free and Pro have no HIPAA path at all. A HIPAA compliant Supabase project is a contract plus a configuration, not a plan you buy.

Verified 5 August 2026 against Supabase’s pricing page, HIPAA Projects guide, shared responsibility model, security page, and HHS guidance.

Hosted Supabase can be part of a HIPAA-compliant system. Supabase’s current documentation requires an organization handling protected health information (PHI) to use at least the Team plan, execute a Business Associate Agreement (BAA), enable the paid HIPAA add-on, mark the relevant projects High Compliance, and maintain Supabase’s required configuration. Free and Pro do not include that path.

Those steps establish and configure the Supabase side of the relationship. They do not establish that the finished app, the customer organization, or every connected service complies with HIPAA. Authorization, risk analysis, workforce controls, permitted uses and disclosures, incident response, and every other place electronic PHI travels remain part of the customer’s scope.

HIPAA is a United States regime for covered entities and business associates. It does not apply to every health app or every item of health-related data. This article is technical and procurement information, not legal advice.

The apps this question usually decides for are patient portals, telehealth booking and visit tools, EHR or EMR integrations, care coordination products, and clinical intake forms. If you are in scope, the downside is not abstract: HHS’s enforcement rule sets civil money penalties in tiers by culpability, from a violation the organization did not know about up to willful neglect left uncorrected, and each tier carries its own per-violation range plus an annual cap for repeated violations of the same requirement, adjusted for inflation each year. Getting the plan tier right is the cheap part of avoiding that.

HIPAA compliant Supabase: what you must have in place

Supabase HIPAA compliance is four things held at once, and missing any one of them means Supabase is not covering PHI for you: an organization on Team or Enterprise, an executed BAA, the paid HIPAA add-on enabled on that organization, and every project touching PHI marked High Compliance with Point in Time Recovery, SSL enforcement, network restrictions, and connection logging on. Supabase’s shared responsibility model states the plan floor in one line: you need to be at least on the Team plan to sign its BAA.

People search this both ways round, and the two phrasings ask different questions. “Is Supabase HIPAA compliant” asks about the vendor, and yes, Supabase is HIPAA compliant as a platform once those four conditions are met. “HIPAA compliant Supabase” asks about your project, and nothing in that list makes your app compliant. Choosing Supabase for HIPAA buys you a place PHI is allowed to sit; the risk analysis, the rule that decides which patient’s row comes back, the workforce controls, and the agreements with everything downstream stay yours. The rest of this page is those two halves in order: what the plan and the contract buy first, then what is still yours afterwards.

Which Supabase plans support a BAA, and what does HIPAA cost?

As of 5 August 2026, Supabase’s pricing page and shared responsibility model support this plan answer:

The plan floor is worth stating precisely, because even Supabase’s own AI assistant has gotten it wrong. The base plans themselves, and what each Supabase plan costs before the add-on, are a separate page; the HIPAA arithmetic stays here.

Warning: the wrong answer to this question is still on page one. A founder asked Supabase’s assistant whether he could get HIPAA coverage on the Pro plan, and 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.” The thread has sat on the first page of results for this question ever since, wrong answer included. There is no HIPAA add-on on Pro. The floor is Team.

Supabase does not publish the HIPAA add-on price on its current pricing page. A Supabase maintainer answered that same GitHub discussion in August 2025 by saying the add-on started at $350 per month for Team or Enterprise. Treat that as a dated public quote, not a current binding price. Ask Supabase for a written 2026 quote before budgeting.

The quote also needs to include required project resources. Supabase currently prices Point in Time Recovery from $100 per month for seven days of retention, and its HIPAA guide says PITR requires at least Small compute. Current list pricing shows Small compute at $15 per month before applying any plan compute credit. Usage, storage, log drains, additional projects, retention, and support can change the total; what Point in Time Recovery actually costs on Supabase lands well above its headline add-on line.

Is Supabase SOC 2 compliant, and is that the same as HIPAA?

Supabase is SOC 2 Type 2 compliant, and no, it is not the same thing. Supabase’s security page states SOC 2 Type 2 compliance, ISO 27001 certification, HIPAA compliance, and support for GDPR-compliant deployments. Its HIPAA compliance guide says Supabase applies the same SOC 2 controls to all environments, with additional controls applied to HIPAA environments, and that it undergoes annual audits in which the HIPAA controls are audited during the same audit period as the SOC 2 controls.

The difference matters the moment someone asks your team for “the compliance certificate”. SOC 2 Type 2 is an attestation: an independent auditor tests a defined set of controls over a defined window and publishes a report, exceptions included. HIPAA has no certification body and issues no certificates. Nobody can hand you a HIPAA certificate for a vendor, because none exists.

So vendor diligence here is two requests, not one. Ask for the executed BAA, and ask for the current SOC 2 Type 2 report. Then read the report for three things: which systems and services are in scope, the testing period it covers (a report whose window closed 14 months ago tells you about last year), and the exceptions section, which is where the useful information lives. ISO 27001 and GDPR are separate questions again, and a health app selling into the EU or UK usually has to answer all of them.

When does HIPAA apply to a Supabase app?

HHS says the HIPAA Rules apply to covered entities and business associates. Covered entities include health plans, healthcare clearinghouses, and healthcare providers that conduct specified electronic transactions. A company outside those definitions does not become HIPAA-regulated merely because its app contains health information. Other federal or state privacy and consumer-protection laws may still apply.

When a cloud provider creates, receives, maintains, or transmits PHI on behalf of a covered entity or business associate, the provider is generally a business associate. HHS’s cloud guidance says the parties need a BAA even when the cloud provider cannot view encrypted PHI.

HHS’s covered-entity and business-associate guidance also makes two boundaries clear:

1. A BAA defines permitted uses, safeguards, reporting, return or destruction, and other contractual duties.
2. Business associates remain directly liable for specified HIPAA duties. Signing a BAA does not transfer every obligation or liability away from the customer.

The BAA must match the real architecture. Confirm the organization, project, region, Supabase products, support access, backups, logs, and subprocessors that may create, receive, maintain, or transmit ePHI. A product name appearing on the pricing page does not answer the contractual scope for Edge Functions, Auth, Realtime, Storage, third-party integrations, or a particular support workflow.

What the BAA itself has to say

Ask for these clauses by name, then read what actually comes back rather than the summary email attached to it:

1. 01 Permitted uses and disclosures, written with minimum-necessary language rather than a broad general grant.
2. 02 Required safeguards, including how role-based access control on the vendor side limits which staff can reach your data and under what approval.
3. 03 Breach notification: what counts as a reportable incident, who makes that call, and the timeline in which you are told.
4. 04 Subcontractor and subprocessor obligations, the current subprocessor list, and how you are notified when that list changes.
5. 05 Data location and residency commitments, covering backups, read replicas, and support access originating in other regions.
6. 06 Termination: return or secure destruction of PHI, in what format, by when, and with what confirmation.
7. 07 Your right to request security documentation, including the current SOC 2 Type 2 report and its scope.

Every one of those is a normal ask. A vendor that will not answer them in writing has answered a different question.

What does Supabase require for a High Compliance project?

Supabase’s HIPAA Projects guide says the BAA and HIPAA add-on come first. Projects in the covered organization can then be marked High Compliance. Supabase runs continuing Security Advisor checks and currently lists four required project configurations:

1. 01 Enable Point in Time Recovery. Supabase says this requires at least Small compute.
2. 02 Turn on SSL Enforcement for incoming Postgres and pooler connections.
3. 03 Enable database Network Restrictions for the approved address ranges.
4. 04 Keep Postgres connection logging enabled so connection events are available for the audit and monitoring process.

The shared responsibility model adds organization-wide MFA, addressing Security Advisor findings, keeping PHI out of public Storage buckets, and avoiding transfer of a covered project to a non-HIPAA organization.

These are Supabase’s service and contract conditions for a HIPAA project. HIPAA’s Security Rule does not name PITR, Supabase Network Restrictions, or the High Compliance switch. HHS instead requires regulated entities to conduct a documented risk analysis and implement reasonable and appropriate administrative, physical, and technical safeguards across all ePHI they create, receive, maintain, or transmit.

Which Supabase products can carry PHI?

The honest answer is that the public pages disagree, and only the executed agreement settles it. Supabase’s healthcare page markets Database, Auth, Row Level Security, Storage, Realtime, Edge Functions, and Vectors under a HIPAA banner, and claims that every data access, every modification, and every login is logged. At least one competing write-up tells readers to keep PHI out of Edge Functions entirely. Both cannot be your operating rule. Take this table into the BAA conversation and get each line answered in writing.

Two of those rows are the ones teams skip. PHI in a public Storage bucket is a disclosure the moment the URL leaves the building, and Supabase’s shared responsibility model makes keeping PHI out of public buckets an explicit customer duty. The AI Assistant data-sharing toggle is the newer trap, because it is an organization setting that one Owner can flip without touching your code.

Where does Supabase’s responsibility stop?

Supabase is responsible for the hosted platform and obligations assigned to it by HIPAA and the executed BAA. The customer remains responsible for the app, people, policies, data, and integrations on its side of the boundary.

Network Restrictions protect direct Postgres and pooler connections. They do not decide which rows a signed-in user can read through Supabase’s HTTP APIs. That job belongs to grants, Row Level Security, views, functions, and the server code using elevated keys. Supabase RLS best practices and whether the platform is safe for your configuration cover those boundaries.

A High Compliance warning also does not prove the application’s ownership rule is correct. Test it with two accounts and disposable records. User B should be refused when reading, changing, exporting, or deleting user A’s PHI through every supported path.

Audit logs and how long they last

The phrase most Supabase HIPAA checklists never use is audit log. Postgres connection logging, one of the four required High Compliance settings, records connection events, and Supabase’s HIPAA guide says it is off by default on new projects, which is why enabling it is a requirement rather than an assumption. Connection events are not a record of who read which patient’s chart. Platform retention is also finite: Supabase’s pricing page lists 1 day of log retention on Free, 7 days on Pro, 28 days on Team, and 90 days on Enterprise. HIPAA’s audit-control standard does not name a matching number, so choose and document a retention period from the events and records your incident process must reconstruct. Log drains are the route to evidence that outlives the platform default, currently priced at $60 per drain per month plus event and egress charges. The application-level record of who viewed, changed, exported, or deleted PHI is still yours to design, write, protect, and be able to produce.

A BAA moves liability. It does not move a plaintext column.

What actually breaks HIPAA in health apps built with AI tools

Three of the 21 third-party apps in the AxonBuild audit corpus stored real clinical data, and all three came out red: 29, 36, and 48 out of 100. One caveat 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.

Every finding there was verified against the code, not pattern-matched, and the full corpus numbers behind the 26 audits carry their denominators with them.

Does HIPAA require application-level encryption for Supabase columns?

HIPAA requires appropriate safeguards, but the current Security Rule does not impose a universal “encrypt every database column” instruction. HHS classifies specified encryption measures as addressable. Addressable does not mean optional: the regulated entity must use its risk analysis to decide whether the measure is reasonable and appropriate, document the decision, and use a reasonable equivalent measure where appropriate.

HHS’s risk-analysis guidance requires the analysis to cover all ePHI an organization creates, receives, maintains, or transmits. Supabase says it encrypts data at rest and in transit and says customers can consider application-layer encryption. Counsel and the security lead should decide what additional encryption or key separation the actual threats require.

The vocabulary underneath that decision is worth having straight. Supabase’s security page says all customer data is encrypted at rest with AES-256 and in transit via TLS, and that sensitive values such as tokens and keys get an extra application-layer encryption pass before they are stored. That is platform encryption. It protects the disk and the wire, and it does nothing about a query that hands the wrong patient’s row to a signed-in user. The options your risk analysis is actually choosing between sit above it: column-level encryption inside Postgres with pgcrypto, tokenization, one-way hashing for values you only ever need to match, and client-side encryption where the platform never sees plaintext. Each one raises the same follow-up question, which is where the keys live, who can reach them, how often they rotate, and whether they are separated from the data they protect. Managed key services with a documented rotation policy exist for exactly that. Whichever way it goes, write down the reasoning, because “we assessed it and here is why” is the artifact HHS asks for.

Encryption also cannot repair an authorization policy that returns the wrong patient’s record to an authenticated user. HHS’s Security Rule summary separately requires access controls, audit controls, integrity measures, authentication, and transmission security.

Does every model provider, logger, and email service need a BAA?

Map the relationship before answering. HHS generally treats a service provider as a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate. A business associate must place the required restrictions on subcontractors that access PHI. HHS also recognizes exceptions, including certain treatment disclosures and entities acting only as conduits.

For a Supabase app, inventory model providers, error monitoring, analytics, email, SMS, support tools, exports, and backup destinations. Determine which receive PHI, for what purpose, and under which legal relationship. Do not send ePHI to a service merely because it advertises security or signs a generic DPA. Review the service scope and execute the appropriate BAA where the relationship requires one.

HIPAA-eligible alternatives to Supabase

The alternatives are the names you would guess: AWS, Google Cloud, and Azure all sign BAAs, and so do Neon and the health-specific platforms that wrap more operational work around the database. What differs between them is how the agreement is obtained and which services it actually covers.

Picking a HIPAA-eligible database is the easy half of the 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. Moving to AWS for HIPAA reasons fixes the plan tier and the contract, and carries a 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.

Supabase HIPAA compliance in practice: a pre-launch evidence check

1. 01 Confirm with healthcare counsel whether the organization and workflow make you a covered entity, business associate, subcontractor, or an entity outside HIPAA. Record any other federal and state rules that apply.
2. 02 Inventory every place ePHI is created, received, maintained, or transmitted, including tables, Storage, Edge Functions, logs, model calls, notifications, exports, devices, backups, and support access.
3. 03 Obtain the executed Supabase BAA and quote. Verify the organization, projects, products, regions, subprocessors, incident terms, return or deletion terms, and every exclusion against the architecture.
4. 04 Enable the HIPAA add-on, mark covered projects High Compliance, apply the required settings, enforce MFA, resolve Security Advisor findings, and keep evidence of the resulting configuration.
5. 05 Test every patient, staff, tenant, admin, and service-role path with identities that should be refused. Include direct API requests and background jobs rather than relying only on the visible interface.
6. 06 Verify audit evidence and recovery. Trigger representative access and failure events, confirm useful records are retained and protected, and restore a real backup into an isolated environment.
7. 07 Document incident detection, containment, business-associate notification, breach assessment, and escalation before launch. A database warning cannot make the legal notification decision for you.

I can trace a defined failure in a working app’s data path and build the change that corrects it. It starts with a free 20-minute video call with me; if you want the change made, I check the app first and give you a fixed quote, and you pay after seeing it work. That work excludes legal advice, regulatory or compliance certification, and penetration testing. It cannot determine HIPAA status, approve a risk analysis, interpret a BAA for the customer, or certify an app as compliant. The wider version of the same pre-launch question is whether your AI-built app is ready to launch.

Common questions about Supabase and HIPAA

Is Supabase HIPAA compliant?

Supabase offers a hosted HIPAA path for Team and Enterprise customers using a signed BAA, the paid HIPAA add-on, High Compliance projects, and required controls. That makes Supabase eligible to support an appropriately designed HIPAA-regulated workload within the agreed scope. Compliance of the customer and finished system still depends on their own legal and operational duties.

Can I use Supabase Pro for PHI?

Supabase’s current pricing table marks HIPAA unavailable on Free and Pro, and its shared responsibility model says an organization needs at least Team to sign a BAA. Do not assume that a later upgrade or BAA will retroactively cover earlier processing; confirm effective dates and migration requirements with Supabase and counsel.

Does signing Supabase’s BAA make my app HIPAA compliant?

No. The BAA establishes contractual duties between the parties. The customer still needs a documented risk analysis, required policies and safeguards, correct application authorization, workforce controls, appropriate downstream agreements, incident procedures, and evidence that those controls operate.

Is Supabase SOC 2 Type 2 compliant?

Yes. Supabase’s security page states that it is SOC 2 Type 2 compliant, and its HIPAA guide says the same SOC 2 controls apply to all environments with additional controls on HIPAA environments, audited annually in the same audit period. SOC 2 is an attestation about tested controls, not a HIPAA certificate, so ask for the current report and read its scope, testing window, and exceptions.

How much does the Supabase HIPAA add-on cost?

Supabase does not publish the HIPAA add-on price on its pricing page. A Supabase maintainer said in an August 2025 GitHub discussion that it started at $350 per month on Team or Enterprise, which is a dated public quote rather than a current price. Budget the Team plan at $599 per month, add PITR from $100 per month and the compute PITR requires, then ask Supabase for a written quote covering the add-on itself.

Are Supabase Edge Functions covered by the BAA?

The public HIPAA pages reviewed on 5 August 2026 do not provide a product-by-product BAA scope, while Supabase’s healthcare page markets Edge Functions under a HIPAA banner and at least one competing write-up says to keep PHI out of them. Ask Supabase to confirm Edge Functions and every other service the workflow uses in the executed agreement. Treat an unanswered scope question as a hold on sending PHI through that service.

Can I store PHI in Supabase Storage?

Only in private buckets, and only if the BAA covers Storage for your organization. Supabase’s shared responsibility model makes keeping PHI out of public Storage buckets an explicit customer duty. Serve files through short-lived signed URLs rather than shareable paths, and treat any place a signed URL gets logged, emailed, or pasted as another route PHI travels.

Which region should a HIPAA Supabase project run in?

HIPAA itself does not require a specific region or US-only storage, so the region is your decision and then a BAA scope item. Pick it from the residency commitments you have made to customers, the other laws that apply (GDPR most often), and latency. Then confirm in writing that backups, read replicas, and support access stay inside that region, because those are the three that quietly leave it.

How long does Supabase retain logs for HIPAA audit evidence?

Supabase’s pricing page lists log retention of 1 day on Free, 7 days on Pro, 28 days on Team, and 90 days on Enterprise. That is platform retention, not an audit trail of who read which record; compare the available window with the events and records your incident process must reconstruct. Use log drains to ship logs to a destination you control, and design the application-level access record separately.

Is self-hosted Supabase covered by Supabase’s HIPAA controls or BAA?

Supabase’s HIPAA guide says the hosted platform’s controls are not supported out of the box in self-hosted Supabase and places self-hosted HIPAA compliance outside its documentation scope. A self-hosted deployment needs its own infrastructure, vendor agreements, controls, risk analysis, evidence, and specialist review.