Supabase can now delete your data in beta features

The change

Supabase is a backend platform built on Postgres. Many startups run their database, sign-in, and file storage on it. On October 5, 2026, Supabase published Version 4 of its Terms of Service, replacing Version 3, which was dated August 1, 2026.

The update is small and targeted. It adds a clause for pre-release features, creates a new layer of Supplemental Terms, and rewrites the clauses on fees, the contracting company, and notices. The first of these matters most, because it changes what Supabase owes you when you build on a feature that is still labeled beta.

What changed

• Beta Releases. A new section 9(c) covers "alpha, beta, pilot, preview, early access, or other pre-general availability products, services, features, or functionality."

• Services. The definition now ends: "For the avoidance of doubt, 'Services' excludes Beta Releases."

• Supplemental Terms. Some features can now be governed by additional terms on a separate page, and those terms come first if they conflict with the main agreement.

• Fees. The clause now covers purchases made through the customer's account and adds: "Customer authorizes Supabase to charge the payment method provided in Customer's account for all Fees."

• Contracting company. The Singapore company is still the default, but customers who buy through a cloud marketplace now contract with Supabase, Inc. in Delaware.

• Notices. Formal notices now go by email, to the address on the customer's account.

The new beta clause

The old terms did not mention beta features at all. The words "beta" and "alpha" do not appear in Version 3, so the terms made no distinction between pre-release features and the rest of the platform. Version 4 separates them, and the new clause does four things.

• It removes the usual commitments. Beta Releases are provided "AS IS" and "AS AVAILABLE," and Supabase "has no support, service level, indemnification, or other obligations with respect thereto."

• It excludes liability. Supabase "will not be liable for any damages, losses, or liabilities" arising from the use of a Beta Release, "including, without limitation, data loss, business interruption, or security vulnerabilities." The one exception is "damages caused by Supabase's willful misconduct."

• It lets Supabase change or withdraw the feature. Supabase "may modify, suspend, or discontinue any Beta Release at any time, with or without notice, and makes no commitment that any Beta Release will be made generally available."

• It covers the data. "Supabase reserves the right to delete all Customer Data submitted to or through such Beta Release, and Customer is solely responsible for exporting or retaining backup copies of any Customer Data it submits to a Beta Release."

The clause also says what a customer would expect it to say: "Customer's use of any Beta Release is optional," and Supabase "will designate each Beta Release as 'alpha,' 'beta,' or with a similar designation." Nobody is moved onto a beta feature by these terms. The change is in what happens to a team that chose one.

Which features carry a beta label

The terms do not list the features. Supabase's documentation does: its features page gives a status for each one. At the time of publication, that page marks Branching, Cron, Database Webhooks, and Auth Hooks as Beta, and Queues, Vault, and the MCP Server as Public Alpha. These are not side experiments. Scheduled jobs, webhooks, and sign-in hooks sit in the middle of many production apps.

The clause does not say where Supabase makes the designation, and the features page is the most visible place it labels features this way. If a feature you depend on is marked alpha or beta, it is safest to assume that the support commitment, the liability terms, and the protection of the data in it are different from the rest of your Supabase project.

Supplemental Terms now come first

The old order of precedence had two steps: "(i) first, this Agreement; and (ii) second, any other documents incorporated herein by reference." The new one has three: "(i) first, any applicable Supplemental Terms, solely with respect to the specific Services, features, or functionalities to which they apply; (ii) second, this Agreement; and (iii) third, any other documents incorporated herein by reference."

The Supplemental Terms are "incorporated into this Agreement by reference." At the time of publication, the page that holds them is labeled Version 1 with the date still to be decided, and it contains no terms yet. So the main agreement now gives first place to a document that is still empty. Whatever is added there later will override the agreement for the features it names. We saw the same pattern, a contract that defers to a page the vendor can edit, when Hotjar's DPA became changeable without a signature.

Fees, the contracting company, and notices

The fees clause used to refer only to fees "identified in the Order." It now also covers services "purchased by Customer through Customer's account," at the fees in the order "or, if none, as stated by Supabase from time to time." It adds the authorization to charge the payment method on the account. For purchases through a cloud marketplace, payment and any refund go through the marketplace, "and not directly by Supabase to Customer."

Notices used to allow personal delivery or courier to a postal address. They must now be "sent by email," and notices to a customer go "to the email address associated with Customer's account." If that address is a former employee's inbox, a formal notice can arrive and go unread.

What did not change

• Data in a beta feature is still Customer Data. The definition was widened to include data submitted "through the Services or any Beta Release."

• "Fees paid by Customer are non-refundable" is in both versions.

• Supabase Pte. Ltd. in Singapore is still the contracting company for customers who do not buy through a marketplace.

• The terms for generally available features are the same as before. The new clause applies only to features that carry a pre-release label.

Why this matters

Developer platforms ship new features early and keep them in beta for a long time. Teams adopt them because they solve a real problem today, and the label fades into the background. Until October, that label had no legal meaning in Supabase's terms. Now it marks the line between a feature Supabase stands behind and one it can change, withdraw, or empty of data with no liability.

Clauses like this are common for beta software, and Supabase is clear that use is optional. The risk is in not knowing. A team that built on a beta feature a year ago agreed to one set of terms and is now under another, without any change to its own code. We saw a similar change to a developer offering when Okta halved the idle window on its free developer plan.

Potential impact

If you build on Supabase, the update raises five practical questions:

• Which features in your project are labeled alpha or beta on Supabase's features page today?

• Does any data live only in one of those features, and do you have your own copy of it?

• If a beta feature were withdrawn without notice, what in your product would stop working?

• Who receives email at the address on your Supabase account, now that formal notices go there?

• Is someone watching the Supplemental Terms page for the day it stops being empty?

How Venpo detected it

Venpo monitors Supabase's legal documents as part of continuous vendor risk monitoring. It recorded Version 4 when it replaced Version 3 and marked each added and removed sentence. Every quote in this article was checked against both versions and against the live page. The redline is on the Supabase change page, and every monitored Supabase document is listed on the Supabase vendor profile.

Business outcome

Teams that track Supabase saw the new beta clause with the old text beside it, which shows that the old text had no such clause. That is enough to list the beta features in use, add backups where data lives only in them, and decide whether any of them is too central to leave on those terms. A team that never saw the change would learn about it from the clause itself, on the day a beta feature changed or its data was gone. Catching that earlier is what vendor contract monitoring is for.

Key takeaway

Supabase's Version 4 terms take alpha and beta features out of the definition of the service, remove support and liability for them, and reserve the right to delete the data in them. They also put a still-empty set of Supplemental Terms above the main agreement. Both changes depend on documents and labels outside the contract, so the way to keep up is to monitor vendor terms of service and the pages they point to.