Does Supabase encrypt my data? Yes. Here is what it stops

A customer emails to ask whether their data is encrypted. Or a bigger client sends a security questionnaire as a spreadsheet, and in it are the rows every questionnaire has: encryption at rest, encryption in transit, your hosting provider's SOC 2 report. Your app runs on Supabase because Lovable or Bolt set it up that way, and until today nobody needed you to know what any of that means.

So, does Supabase encrypt your data? Yes. All of it, on every plan, and the certificates behind the claim are real.

Where most answers go wrong is in stopping there, as though encryption decided who gets to read your data. It decides something narrower. Think of Supabase as a bank. Encryption at rest is the vault, encryption in transit is the armoured van, and SOC 2 is the inspector who checks that both are run the way the bank says. Every one of them is about somebody who was never meant to be inside. The rule at the counter, about whose statement a customer may ask for, is a separate thing, and your project is where it gets written.

Every figure below was read off Supabase's pages and documentation on 29 September 2026.

Does Supabase encrypt my data?

Yes. Supabase's security page states that all customer data is encrypted at rest with AES-256 and in transit with TLS, and there is nothing for you to switch on.

At rest means on the disks. Your database is written to storage in encrypted form, so a copy of the disk taken away from Supabase's machines is unreadable on its own.

In transit means on the way between your visitor and Supabase. Your app talks to Supabase through its web APIs, for data, sign-ins and files, and Supabase's SSL enforcement guide says every one of those APIs refuses an unencrypted connection. The exception is a direct connection to the Postgres database underneath, the kind a backup tool or a server of your own might open. Those accept an unencrypted connection until you turn on Enforce SSL on incoming connections under Database Settings. Your visitors' browsers never open one.

Column encryption is the one layer that stays off. It keeps a single value, a phone number say, scrambled even inside the database. Supabase used to document a way to do it, and its pgsodium page now recommends against that feature, citing its operational complexity and the risk of misconfiguring it, and adds that encryption at rest is likely enough for SOC 2 and HIPAA. For secrets such as a third-party API key there is Vault, which stores them encrypted and hands them back through a view.

What does Supabase's encryption stop?

Anyone who reaches your data without asking the database for it. Somebody who walks off with a disk, copies a backup file, or listens in on the traffic between a browser and Supabase gets scrambled bytes and nothing else.

A request the database decides to answer is another matter. Encryption at rest works underneath Postgres, so the database reads its own files as plain data, for every query it serves. Which queries it serves is settled by the permissions on each table. In Supabase that is Row Level Security, the rule saying which rows each visitor may read, and each table needs it switched on with a rule written for it.

That is the counter in the bank. The vault opens for the teller every time, because the teller works for the bank. If nobody wrote down whose statements a customer may see, the teller hands over whatever is asked for, and the armoured van delivers it, sealed all the way, to whoever asked.

Supabase's documentation says the same about Vault, which does encrypt values inside the database: "anyone that has access to the view has access to decrypted secrets."

Does encryption stop a stranger reading my tables?

No, and we measured how often that matters. In August 2026 we scanned 30,998 live apps built with Lovable, Base44, Replit, v0 and Bolt. In 3,680 of them we could complete the check that asks a Supabase database, with no login, whether a table will hand over its rows. In 2,096 of them, 57%, at least one table would, and 394 of those had an open table named after people: users, profiles, customers, orders.

Every one of those databases was encrypted at rest the whole time, by the platform's own account of how it runs, and any stranger who asked would have been sent the rows over TLS. Nothing about the encryption failed, and it played no part in deciding who got an answer.

The request itself is ordinary. It is the one your own app makes to show a signed-in customer their orders, sent without the sign-in: the public key that is meant to be in your page, and a GET to /rest/v1/ with a table name on the end. Our scan read how many rows each table would return and stopped there, without fetching one. The full measurement sets out what that 57% is a share of and how much we could not see.

Is Supabase SOC 2 compliant?

Yes. Supabase holds a SOC 2 Type 2 report from an independent auditor, renewed every year.

A SOC 2 report is an auditor's account of whether a company's security controls worked the way the company says they do. Type 2 means they were tested across a whole period, and Supabase's runs from 1 March to 28 February. It covers security, availability, processing integrity, confidentiality and privacy, across the database, Storage, Auth, Realtime, Edge Functions and the Data API, and Supabase's SOC 2 page marks where it ends:

Supabase's SOC 2 compliance does not transfer to environments outside of the Supabase product or Supabase's control.

In the bank, that is the inspector's report on the vault and the vans. Your table rules sit outside it, because you write them: Supabase's shared responsibility model lists access management and applying security controls among the things a customer is always responsible for.

Two more things follow from that. If a client needs your company to be SOC 2 compliant, Supabase's SOC 2 page says a customer in that position has to put the controls in place and go through an audit of its own. And whether Supabase is a sound platform to build on at all is a separate question with its own article.

How do I get Supabase's SOC 2 report?

From your organization's dashboard, on the Team plan or above. It sits under Legal Documents, next to the ISO 27001 certificate and Supabase's standard security questionnaire, and an organization on Free or Pro finds an upgrade button there instead.

Team starts at $599 a month, where Pro starts at $25, so it helps to know what the difference buys. Supabase's documentation says every project is governed by the same set of compliance controls, so a project on Pro runs on the same audited platform. Team adds the documents, along with single sign-on for the dashboard, daily backups kept for 14 days where Pro keeps 7, and eligibility for HIPAA. If a client asks for the report itself, ask whether Supabase's public security page will do before you change plans for one PDF.

Is Supabase ISO 27001 certified?

Yes, to ISO/IEC 27001:2022, which Supabase announced on 22 April 2026.

ISO 27001 certifies a management system: the policies, risk assessments and processes a company uses to look after the information it holds. An accredited auditor issues the certificate for three years and comes back every year in between to check the system is still running. In the bank, it is the inspector reviewing how the security procedures get decided and kept up to date. Supabase's announcement describes SOC 2 as widely accepted in North America and ISO 27001 as widely accepted in Europe, Asia and the public sector. The certificate is in the same Legal Documents section, on the same plans.

Is Supabase HIPAA compliant?

It can be for your project, once you sign a Business Associate Agreement with Supabase and pay for its HIPAA add-on. It is not automatic, and Supabase's SOC 2 page says SOC 2 does not stand in for it.

A Business Associate Agreement, or BAA, is the written contract US health law requires before a company may handle protected health information on your behalf. Supabase signs one on the Team plan or above. The add-on has no published price: you send a request, Supabase replies with the price and the process, and a Free or Pro organization that applies still has to move to Team once it is approved.

Signing is where your part starts. Supabase's shared responsibility model lists what a HIPAA customer has to do, and these are the items an app owner is least likely to have met:

• Mark the project as a HIPAA project, and act on what the Security Advisor raises about it.
• Turn on two-factor sign-in for every account in the Supabase organization.
• Turn on point-in-time recovery, which needs at least the Small compute add-on.
• Turn on SSL enforcement and network restrictions.
• Keep health data out of public storage buckets.

Encryption at rest and in transit is on that list as well, and it is the one item Supabase has already done.

Is Supabase GDPR compliant?

Supabase supports GDPR-compliant apps and supplies the two pieces only it can. Whether your app complies depends on what it does with people's data.

The first piece is location. You pick a region when you create a project, and a specific EU region keeps your database, Auth and Storage there. Choose the region by name, because Supabase's general Europe option also includes London and Zurich. The second is the Data Processing Addendum, the contract GDPR requires between you and a company processing personal data for you. Supabase's forms part of its Terms of Service, so every organization already has one.

The rest belongs to your app: why you collect each field, how people agree to it, who can read it and how you delete it when asked. Supabase's GDPR page says outright that picking a region does not make an application compliant on its own. What your app owes under the law is a question for a lawyer.

How do I answer a client's security questionnaire?

Split it into two piles before you write anything. Some rows ask about Supabase's platform and are answered from Supabase's documents. The others ask about your project, and you are the only person who can answer them.

The Supabase rows copy straight across from its documents. The last three are the ones the client sent the questionnaire to find out, and answering them needs your own project open in front of you.

What do I tell a client who asks who can read the data?

The state of your policies, table by table, and the date you last checked them. "The data is encrypted" answers a question about stolen disks, and a client asking about access is asking about the counter.

A straight answer names the tables that hold personal data and says each has Row Level Security switched on, with a policy tying every row to the signed-in person it belongs to. It says when you last checked from outside, as a visitor with no login, that those tables returned nothing. If a table is public on purpose, a product list or published posts, it says that too. Then the admin side: who can open your Supabase dashboard, with two-factor on, and where the secret key lives. That key is service_role in older projects and sb_secret_… in newer ones, and it belongs on a server.

To find the state of your tables, start with the Security Advisor in your Supabase dashboard, which lists every table with Row Level Security switched off. A table can pass that and still be open, through a policy that lets everyone in. The four states a table can be in shows how to tell them apart, and there is a plain-language walkthrough for Supabase apps.

Write down only what you have checked. If you have not read a table's policy yet, give the date by which you will.

How Reeve checks the answer from outside

The rows a questionnaire leaves to you are about who gets an answer. Reeve asks your live app the way a stranger would and tells you which tables answered.

• The free scan asks every table your app names how many rows a visitor with no login would get, reads the count and stops without fetching a row. About 20 seconds, no account: scan your app.
• Reeve Monitor re-runs all nine checks every hour on up to three apps and emails you the day your grade gets worse, so a table your builder adds after the questionnaire went back is checked within the hour.
• Care runs the same checks and keeps a copy of your Supabase database outside your Supabase account, taken on a schedule and read back before it counts, which answers the backup row. Each copy is encrypted with AES-256-GCM under a key that belongs to your account alone, and our legal page explains how those keys are kept. How a copy is taken and put back.

What each plan covers and costs is on the pricing page.

What to do now

The encryption half of the questionnaire is already answered for you. Before you send it back, scan your app and see which of your tables answers a stranger today.