Supabase alternatives, compared on what you would have to rebuild

Most founders searching for Supabase alternatives should fix the reason first and switch second. Neon, Firebase, Convex, Turso, PlanetScale, Appwrite, PocketBase and Nhost each replace some or all of Supabase’s bundle, so leaving means rebuilding auth, file storage, access rules and backups. Switch for a real constraint, such as the data model or price at scale.

Is there anything better than Supabase? What you are comparing, and for whom

Something better than Supabase exists only for a named constraint: a document data model, SQLite files close to the user, logic in TypeScript functions, or a database without the bundle. Most reasons founders give for leaving, such as a broken access rule, a paused free project or a missing backup, follow the app to the next platform.

The set compared here is Supabase and eight Supabase competitors, read from each vendor’s own docs and pricing pages on October 5, 2026: Neon, PlanetScale, Turso, Firebase, Convex, Appwrite, PocketBase and Nhost. The reader we have in mind runs one app, live or close to launch, and is deciding where its data, sign-in and files should live. Whatever you can use instead of Supabase sits in one of the three groups in the next section. Why so many apps start here in the first place, and the platform’s own weak spots, are covered in why so many AI-built apps start on Supabase and are not repeated here.

Start with the reason you are looking. The table sorts six reasons for leaving by whether a new platform removes them, and only the last one does.

The pause rule and what each paid tier adds are set out in what Supabase’s free plan holds. If speed is the complaint, check is Supabase slow, or is it the app before you price a move.

The access-rule row is the one with numbers behind it. We audited 21 third-party apps in June and July 2026: 9 of them had row-level security gaps, and 7 had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. Those 21 were apps we picked, not a random sample, and our findings are not split by backend, so neither figure is a rate for Supabase apps.

Supabase alternatives compared: what you would rebuild on each

Supabase alternatives fall into three groups: database platforms (Neon, PlanetScale, Turso), full backends with a different model (Firebase, Convex), and open-source bundles you can host yourself (Appwrite, PocketBase, Nhost). The further an option sits from Postgres and SQL policies, the more of the app you rewrite.

Every cell below comes from the vendor’s own docs or pricing page; where a page does not say, the cell says so. The last column is our reading, not the vendor’s: for each of these alternatives to Supabase, it names what an app already running on Supabase would rebuild, among sign-in and sessions, access rules, file storage, realtime, functions and backups.

Plans and features checked October 5, 2026, on each vendor’s own docs and pricing pages.

The best Supabase alternative is the one whose missing pieces you were not using anyway. An app that only stores rows can move to a database platform with little rework; an app that leans on Supabase Auth, Storage and Realtime at once changes all three wherever it goes. On free plans, the Supabase alternatives differ: Neon, Turso, Convex, Appwrite and Nhost offer one, Firebase gives a daily quota, PlanetScale has none, and PocketBase has no hosted plan to price. Of those with a free plan, Appwrite and Nhost, like Supabase, pause a free project left idle. No single alternative to Supabase wins across all three groups, because each group answers a different constraint.

When to pick each

Each option below has a fit, a misfit and one disqualifier, in the vendor’s own terms where the vendor states them.

Neon vs Supabase: keep Postgres, rebuild the rest

Neon is the closest Supabase alternative for an app that mostly wants Postgres: the same SQL, the extensions Neon supports, and branching for copies. It now ships its own auth, object storage and functions, but realtime is a backend you host yourself on its functions, and code written against Supabase’s services is rewritten for Neon’s.

Neon calls itself “the backend for apps and agents”, built around “Serverless Postgres with branching, autoscaling, scale to zero, and instant restore”. Its auth is “Managed Better Auth with sign-up, OAuth, and sessions”, where users live in your Postgres, and on the Free plan it covers up to 60,000 monthly active users, according to Neon’s pricing page. Access rules stay Postgres row-level security, with Neon’s Data API supplying the user id the policies check. So the database and the row-level security approach carry over; the sign-in system, the storage calls and the server functions are new code against new services.

Neither platform is better in general. Neon fits when the database is the part you want to change, such as branching a copy for each preview; Supabase fits when you use its bundle as it is. Among alternatives to Supabase for pure Postgres, Neon sits beside PlanetScale and the managed Postgres hosts its own migration guides list, such as Amazon RDS, AlloyDB, Cloud SQL and Azure. The disqualifier is an app that depends on Supabase Realtime, because Neon’s docs have you host a real-time backend yourself on Neon Functions, with WebSockets or server-sent events.

Convex vs Supabase: TypeScript functions instead of SQL policies

Convex replaces Postgres and SQL policies with a document-relational database and TypeScript functions, where every read, write and access check is code. It suits a team that wants its backend logic in one language; it means rewriting every query and policy the Supabase app already has.

In Convex’s docs, queries are “pure functions that can only read from the database” and mutations are “transactions that can read or write from the database”, and a query reruns and updates its subscribers when the data it read changes. Sign-in comes from a provider such as Clerk, WorkOS AuthKit or Auth0, or from the Convex Auth library, which Convex’s auth overview says “is in beta (it isn’t complete and may change in backward-incompatible ways)”. Authorization has no policy layer: the docs say the common way is “to simply write code that checks if the user is logged in and if they are allowed to do the requested action at the beginning of each public function”. Self-hosting is documented, and the self-hosted build “runs the open-source backend”.

Convex is better than Supabase for a team that would rather write access checks in TypeScript than in SQL, and that is starting fresh or close to it. For an app that already exists, Convex as a Supabase alternative has one disqualifier, the size of the rewrite: every row becomes a document, every RLS policy becomes code inside a function, and the SQL tools you used to inspect data stop applying.

Turso vs Supabase: SQLite at the edge

Turso runs libSQL, which its docs call “a fork of SQLite, created because SQLite is open-source but not open-contribution”, and it now also builds Turso Database, “a ground-up rewrite of SQLite”. With embedded replicas, reads “run locally from the file in microseconds” while writes go to the cloud primary. Per Turso’s point-in-time recovery docs, restoring “creates a new database”, so the app needs the new connection string. Free plan users can restore to any point within the last 24 hours, and Developer, Scaler and Pro users within the last 10, 30 or 90 days.

The comparison of Supabase vs Turso also changed in October 2026. On October 2, Turso announced that it “is being acquired by Supabase”. Its post adds: “Turso keeps running. Your databases, APIs, and workflows continue as they do today.” Since the service keeps running as it does, the fit below still holds.

Turso fits many small databases, one per tenant or per device, with reads close to the user; its Free plan already allows 100 databases. It does not fit an app that leans on Postgres features, Postgres extensions or row-level security. Turso’s docs leave app sign-in to an outside provider (Clerk or Auth0, in beta) and do not state file storage, so a move from Supabase to Turso rebuilds both elsewhere.

PlanetScale vs Supabase: a managed database, not a backend bundle

PlanetScale offers “Vitess (MySQL-compatible), Neki, and Postgres” databases on a self-serve Base plan or an Enterprise plan. Its plans docs say it “does not offer a free plan” and that “All databases require a paid subscription starting with our Base plan”. Its pricing page starts a single Postgres node at $5 a month, for “Development and low-traffic production workloads”, and PlanetScale’s pricing docs bill the high-availability setup as one primary and two replicas.

There used to be a free tier. PlanetScale’s own FAQ on the change set the dates: from March 6, new Hobby databases could no longer be created, existing ones had to “upgrade their database to a paid plan by April 8, 2024”, and databases not upgraded by then “will be put into sleep mode”, with a backup copy archived and the option to wake a database for 24 hours to retrieve the data. The lesson we take from it: a free plan is a pricing decision the vendor can change, so pick the platform whose exit you could afford on its timetable, not yours.

In a Supabase vs PlanetScale choice, PlanetScale fits a team that wants a database with explicit operations and pays from day one. It does not fit an early app that uses Supabase for sign-in and file storage too: neither is stated in PlanetScale’s docs, so both would come from other services.

Firebase: a different data model, chosen on purpose

Cloud Firestore is “a cloud-hosted, NoSQL database” that bills for “The number of documents you read, write, and delete”, the index entries a query reads, storage and network bandwidth; the free quota is 50,000 document reads, 20,000 writes and 20,000 deletes a day and 1 GiB stored, per Firestore’s billing page. Access is written in Security Rules, which Google says use “a unique language built to accommodate more complex rules-specific structures”, and “The server client libraries bypass all Cloud Firestore Security Rules”.

Firebase fits a mobile app with a document model, where Firestore’s offline cache lets the app “write, read, listen to, and query data even if the device is offline”. It does not fit relational data that leans on joins: in our reading, each join turns into extra document reads or copied fields, and Firestore bills by the documents you read. The full two-way comparison is Supabase vs Firebase, side by side.

Open-source Supabase alternatives: Appwrite, PocketBase and Nhost

Appwrite, PocketBase and Nhost are the open-source Supabase alternatives that also bundle auth and storage. Appwrite and Nhost offer a hosted plan and a self-host path; PocketBase is one file you run on your own server, which also makes you its backup and upgrade process.

Appwrite says “Appwrite is open source” and can run on any operating system that can run a Docker CLI, with “You manage updates and scaling” as the trade, per Appwrite’s self-hosting guide. Its cloud Free plan pauses a project after “no development activity for 7 consecutive days”, and since June 29, 2026, free projects that stay paused for 90 days are deleted. The disqualifier: access moves from SQL policies to Appwrite permissions on tables, rows, buckets and files, and the app’s calls move to Appwrite’s own SDKs and APIs.

PocketBase’s docs describe “an open source backend consisting of embedded database (SQLite) with realtime subscriptions, builtin auth management, convenient dashboard UI and simple REST-ish API”. Its FAQ answers the hosting question with “No. PocketBase is self-hosted only”, and the scaling one with “Only on a single server, aka. vertical.” The disqualifier is that you are the operations team: backup is a copy of the pb_data directory, and the docs warn that backward compatibility “is not guaranteed before reaching v1.0.0”.

Nhost runs a dedicated Postgres instance with the Hasura GraphQL Engine, realtime subscriptions and role-based authorization, and its open-source repository says you “can self-host the whole Nhost stack”. Nhost’s pricing page lists a free Starter plan limited to 1 project, “paused after 1 week of inactivity”, with automated backups starting on Pro. The disqualifier: the database stays Postgres, but the app’s calls move to GraphQL and its policies to Hasura roles.

Self-hosting Supabase instead of leaving

A self-hosted Supabase is the one alternative that keeps your schema, policies and client code as they are. Supabase’s self-hosting guide documents Docker Compose, with Kubernetes as a community-maintained option. What you take on is the list the guide gives: server maintenance, security patches, Postgres maintenance, high availability, “Backups and disaster recovery” and “Monitoring and uptime”. Some platform features do not come along, among them branching and “managed backups and PITR”.

It fits a data-residency rule or a customer who wants the app on their own servers. Running the exported app yourself is covered in how to self-host an app you exported, and the deploy, rollback and ownership controls a small team then runs alone are in DevOps for startups.

What a switch will not fix, and how to leave if you still should

A platform switch does not fix access rules, backups or settings the app never had. The policy that let one user read another’s rows is rewritten on the new platform, in its language, by the same process that wrote the first one; the untested restore stays untested.

Three controls move with the app whatever the host. Access rules have to cover every table, which on Supabase means the patterns in Supabase RLS best practices. A restore has to have been run at least once, start to finish. And the platform’s own risky defaults have to be changed, which is the job of how to harden managed database settings. When a team outgrows Supabase or Neon and needs production-grade resilience, the usual modernization path is hardening on the platform it has, then moving one service only if a named limit requires it.

These three are deliverables of the Production Hardening Sprint: data isolation across every table (1.4), verified backups and restore (4.7) and managed-platform security settings (2.9). The sprint does that work on whichever provider the app already uses, as the next section sets out.

If leaving is still right, this order keeps a way back at every step, and each step leaves evidence you can keep:

1. 01 Write down, in one sentence, the constraint that forces the move. Keep that sentence; it is how you judge every later trade-off.
2. 02 Export the data and the schema, and restore both into a staging copy on the new platform. Keep the row counts from both sides.
3. 03 Rebuild sign-in first, then access rules, then file storage, then realtime, and test each with two user accounts. Keep the record of what each account could and could not read.
4. 04 Run both platforms side by side, with writes going to one of them. Keep the log of any difference you find.
5. 05 Cut over, and keep the old project read-only. Keep its connection details until the next step is done.
6. 06 Delete the old project only after the first restore on the new platform has succeeded. Keep the restore record.

The Supabase half of step 2 is in back up and restore a Supabase project, and the parts that tend to fail during a move are in what breaks when you migrate an app.

How the sprint handles this choice

If the reason you were looking is a risk on the platform you already have (an access rule, a restore nobody has run, a dashboard default), and a launch, an investor review or paying customers are close, that is the work worth handing over. Start with a free audit: a video call where we go over the risk that sent you looking and agree whether it can be fixed on Supabase itself. In the sprint, we then make the app you have production ready through the published scope, on the provider and stack it already runs: your app’s current framework and hosting setup are our starting point, and we refactor or replace components where the production work requires it.

Common questions about leaving Supabase

Is Supabase too expensive?

Usually not for a small app: the Free plan costs $0, and Pro starts at $25 a month with the first project included and more projects from $10 a month, as of October 5, 2026. What grows a Supabase bill is usage, such as compute and egress, and moving to another platform puts the same usage on that platform’s meters instead.

Is PlanetScale not free anymore?

PlanetScale has no free plan anymore: its plans docs say it “does not offer a free plan”, and a single Postgres node starts at $5 a month, as of October 5, 2026. The old Hobby tier had a deadline of April 8, 2024: databases not upgraded to a paid plan by then were to be put into sleep mode.

Is neon tech free?

Yes, Neon has a Free plan at $0 a month, with 100 projects, 100 CU-hours of compute a month per project and 1 GB of storage per project, as of October 5, 2026. Free compute scales to zero after five minutes idle, Managed Better Auth is included for up to 60,000 monthly active users, and the Launch and Scale plans above it are usage-based.

How much does PocketBase cost?

PocketBase is open source and “self-hosted only”, so what it costs is the server you run it on, plus the time to back it up and upgrade it. Its FAQ says there is “no paid team or company behind it”, and for small proof-of-concept and hobby apps it points to free cloud tiers, such as Google Cloud’s.