Supabase Alternatives: What You Actually Own After the Switch

The best Supabase alternative depends on which part of Supabase you need to replace. Supabase bundles a database, authentication, file storage, realtime, and serverless functions into one backend as a service (BaaS), so one swap is really five swaps. Neon and PlanetScale keep PostgreSQL. Firebase and Convex replace the data-access model. Appwrite and Nhost replace the whole bundle. PocketBase and Directus let you own the box. Turso moves the application toward SQLite. A managed PostgreSQL service supplies the database while leaving auth, file storage, realtime behavior, and an API layer to your application.

Short version:

• Stay on Supabase if the reason for leaving is a wrong RLS policy, a slow query, or a bill nobody has read line by line.
• Self-host Supabase if you want the same SDKs and the same Data API on your own server, and you have someone to run backups and upgrades.
• Pick Neon if you want PostgreSQL plus branching and scale-to-zero, and will source auth and storage yourself.
• Pick PlanetScale Postgres if you want a dedicated cluster per branch and an explicit high-availability choice, and you can pay before the first user exists.
• Pick Firebase if the product is mobile-first with offline sync, and you accept a document model instead of SQL.
• Pick Convex if you want a reactive TypeScript backend and will write every authorization check by hand.
• Pick Turso if you want SQLite-compatible, local-first, or database-per-tenant data.
• Pick Appwrite if you want the closest like-for-like bundle to Supabase with a credible self-host exit.
• Pick PocketBase if the app is small, single-server, and you want one binary you can copy to a box.
• Pick Nhost if you want PostgreSQL plus a GraphQL API instead of PostgREST.
• Pick Directus if you already have a SQL database and only need an API, an admin UI, and roles on top of it.
• Pick managed PostgreSQL if your own backend already enforces authorization and Supabase was only the database.

For an app already using Supabase Auth, Storage, the Data API, and Edge Functions, staying is usually the lowest-risk choice. Switching becomes rational when a measured constraint has a clear owner: PostgreSQL branching, document sync, a TypeScript-native reactive backend, SQLite-compatible local data, read replicas or multi-region reads, connection pooling limits at peak, infrastructure control, a compliance requirement the current plan cannot meet, or a cost shape your workload can demonstrate.

Every number here comes from the vendor’s own documentation. The PostgreSQL and NoSQL options were rechecked on 2 August 2026, and the open-source options on 5 August 2026. Two version-level markers worth carrying into a 2026 decision: Convex is open source under a fair-source license whose code converts to Apache 2.0 two years after each commit, and PocketBase is still pre-1.0 and says so. Plan limits and prices move, so read the linked page before you buy or migrate.

Supabase alternatives at a glance

Seven more names come up in versus-Supabase searches without belonging in the table above, because each replaces one layer rather than the bundle. Naming them is usually the fastest way to end the comparison.

Migration cost tracks engineering shape, not a quoted number of days. Split it in two: the SQL that moves, and everything Supabase supplied around it.

A database-only project may move in an afternoon. An app using Supabase Auth identities, Storage objects, Realtime subscriptions, Edge Functions, cron jobs, and webhooks has six separate migrations even if pg_dump completes in minutes.

Why founders look beyond Supabase

The current Supabase limits that most often trigger a comparison are concrete. Its pricing page says Supabase may pause a free project after low activity over a seven-day period, with a warning email before the pause, and limits an account to two active free projects. Pro starts at $25 per organization, includes compute credits for one Micro project, and additional projects begin around $10 per month. Pro includes daily database backups retained for seven days. Seven-day point-in-time recovery starts at $100 per month per project.

Security configuration is another source of friction, but moving platforms does not remove it. Tables created in Supabase’s Table Editor have RLS enabled by default. Tables created with SQL or migrations need RLS enabled explicitly. Supabase’s Data API security guide now explains the complete boundary: grants decide which roles can reach an object, and RLS decides which rows they can use.

Before moving, write the reason in a form you can test:

• “The free project pause interrupts this demonstration environment.”
• “This workload needs cheap, short-lived PostgreSQL branches for every preview.”
• “Per-document billing matches our sparse mobile reads better than a running database.”
• “The application needs an embedded SQLite-compatible database that syncs.”
• “We need read replicas in a second region for reads our users actually make.”
• “We are hitting connection pooling limits at peak and the fix is not in our code.”

“Supabase feels risky” is too broad to select a replacement. Whether Supabase is safe separates platform controls from the app’s configuration, which is the cheaper diagnosis to make first.

Self-hosting Supabase itself

Self-hosting is the option between staying and rewriting, and it is the one most comparison pages skip. Supabase’s self-hosting guide calls Docker the fastest and recommended way to do it. The client SDKs, the Data API, the auth flows, and the RLS model all stay the same, so your application code does not change. That is the whole point: you change hosting without changing the API surface.

Best for

A team with an existing on-call rotation, a data residency requirement, or a hard rule against a hosted control plane. Also anyone whose objection to Supabase is where it runs rather than how it works.

Where it falls short

An AI-built app with one founder. Supabase’s own list of what becomes yours when you self-host is server provisioning and maintenance, security hardening and OS updates, service configuration, PostgreSQL maintenance, high availability and scalability, backups and disaster recovery, and monitoring and uptime. That is a job, not a checkbox.

What you still have to build

A self-hosted install mimics a single project. Supabase says branching, advanced metrics, managed backups, point-in-time recovery, and analytics are unavailable in a self-hosted configuration. If the reason you were shopping was better recovery, self-hosting moves you backwards unless you build the backup and restore pipeline yourself and test a restore.

Firebase: choose a different data model deliberately

This is the original head-to-head. Supabase’s architecture page says it builds many of the features Firebase offers out of entirely open source tools, and that it is not a one-to-one mapping of Firebase. Firebase is the strongest alternative when the product fits Firestore’s document model, mobile SDKs, offline behavior, and Firebase Authentication. It is a substantial rewrite for a relational Supabase app.

Best for

Mobile and web products where offline sync, the client SDKs, and Firebase Authentication are the reason for the move. Choose Firebase when its client and sync model is the point. Avoid it as an attempted one-for-one PostgreSQL host swap.

Where it falls short

Firestore security rules evaluate client requests, but they are not filters. A query must be compatible with the rule’s potential result set. Google’s secure-query documentation also states that server client libraries bypass Firestore Security Rules and use Google Cloud credentials, so server-side access belongs under IAM and application authorization.

The billing unit changes too. Firestore charges for document reads, writes, deletes, index-entry reads, storage, and bandwidth. Its billing guide lists a daily free quota, 50,000 document reads per day at the 2 August 2026 recheck, and notes that PITR, backup data, restores, and clones require billing. A page that reads 100 documents incurs at least 100 document reads; rule evaluation and index entries can add more depending on the query.

What you still have to build

Server-side authorization under IAM, a document-shaped replacement for every join, and a cost model per screen rather than per instance. Firebase now also offers SQL Connect, the managed PostgreSQL path it renamed from Data Connect in March 2026, which makes “Firebase equals NoSQL” incomplete in 2026. It still does not turn an existing Supabase project into a drop-in migration, because the API, authentication wiring, configuration, and pricing model remain different.

A separate Firebase security analysis covers what Google secures and what is still on you. This comparison keeps the narrower migration question: which responsibilities change hands when Supabase leaves the stack.

Neon vs Supabase: keep PostgreSQL and replace the bundle selectively

Neon is the closest fit when the database is the main concern. It provides PostgreSQL, autoscaling, scale-to-zero, database branches, and point-in-time history. Existing SQL and the PostgreSQL part of an RLS policy can move with fewer changes than they would require on Firebase, Convex, or Turso. Supabase-specific helpers such as auth.uid() and auth.jwt(), mapped roles such as anon and authenticated, and assumptions about JWT claims still need replacing.

The old shorthand that Neon has “no auth” is no longer accurate. Neon’s current pricing and plan page includes Neon Auth, with plan-specific monthly active-user limits. At the 2 August 2026 recheck, the Free plan included 0.5 GB of storage and 100 compute-unit-hours per project per month, and paid plans were usage-based with no monthly minimum, a different cost shape from Supabase’s $25 floor. Free also includes a limited restore window, while paid restore windows can extend to seven or thirty days depending on plan. Compute, storage, history, branches above the included allowance, and egress have separate usage rules.

Best for

A PostgreSQL-first app that values branching or scale-to-zero and wants to choose the surrounding services independently. Preview environments per pull request are the clearest single reason.

Where it falls short

Neon is a database, not a bundle. There is no object storage, no realtime channels, and no serverless function runtime to inherit. There is no official self-hosting path either, so “open source database” does not translate into “run it yourself.” A usage-based bill is also harder to predict than a flat $25 until you have a month of real traffic.

What you still have to build

Supabase Storage, Realtime channels, Edge Functions, generated Data API behavior, dashboard workflows, and provider-specific authentication hooks do not move merely because both databases speak PostgreSQL. Inventory those surfaces before describing the migration as a connection-string change.

PlanetScale: dedicated PostgreSQL or Vitess with explicit operations

PlanetScale now offers two database engines: PostgreSQL and Vitess, its MySQL-compatible platform. An existing Supabase app evaluating PlanetScale Postgres can retain PostgreSQL syntax and use native RLS. The Vitess route is a different migration and should be evaluated separately.

PlanetScale Postgres uses a cluster per branch. Its pricing documentation lists single-node development or cost-sensitive clusters and three-node highly available configurations. At the 2 August 2026 recheck, a single-node PS-5 Postgres cluster cost $5 per month and the same size with high availability across three nodes cost $15.

The backup documentation says every Postgres branch receives an automatic backup every 12 hours, with two days of default retention and PITR through retained WAL. Restores create an independent branch, which is useful for verification before promotion.

Best for

A team that wants a dedicated database topology, branch-based operations, and an explicit high-availability choice rather than an implicit one. The restore-into-a-new-branch behavior is genuinely good operational design.

Where it falls short

There is no free tier. PlanetScale retired its Hobby plan in April 2024 and has not brought one back, so you pay before your first user exists. It is a harder sell for an early prototype that relies on Supabase mainly because several backend services arrive together. A small single node should not be compared with an HA production service as though the two provide the same failure tolerance.

What you still have to build

Auth, object storage, realtime, and the API layer all belong elsewhere. PlanetScale gives you a database and the operational surface around it, and stops there deliberately.

Convex: move authorization into TypeScript functions

Convex replaces the relational database surface with reactive queries, mutations, actions, and TypeScript-defined server functions. That can reduce the gap between frontend and backend code, but it changes where access control lives. Convex is open source under a fair-source license, and its self-hosting guide documents running the same backend code on your own servers.

Best for

A product where reactivity is the feature: live dashboards, collaborative editing, anything where a query result should update itself. A TypeScript team that wants one language across the stack gets real leverage here.

Where it falls short

Convex’s authentication overview states that deployment endpoints are exposed to the internet and that public requests must be checked against authorization rules defined in code. Convex authenticates compatible OIDC tokens and supports integrations with providers such as Clerk, WorkOS, and Auth0. It deliberately does not impose a database RLS model.

That boundary is viable when every public function derives the caller from verified identity and checks access to the requested object. A function that accepts userId from the client and queries on that value has the same ownership flaw as a permissive RLS policy.

I audited an AI fitness app on Convex where that flaw was concrete. Login was enforced in the React tree and on two protected page URLs, the part a demo exercises. The functions behind them asked for no proof of identity at all: getUserIdentity appeared nowhere in the repository, every function was public, and the get-plans query filtered on a userId the caller supplied instead of the verified identity. The backend URL ships in the browser, so a stranger who never logged in could read anyone’s diet and workout plans, overwrite any profile, and trigger the paid model on repeat. The fix was one line per function, deriving the user from the verified identity. Nothing visible from outside would ever have told anyone it was missing.

Authorization written in a policy fails loudly on the wrong query. Authorization written in a function body fails silently on the query nobody wrote a check for.

What you still have to build

Queries, mutations, background actions, authorization tests, and operational tooling all change. Every public function needs its own ownership check, and you need a test that proves it from a second account. Choose Convex because its reactive TypeScript model fits the product, not because it removes the need to design authorization.

Turso: choose SQLite compatibility and local data

Turso Cloud supports both libSQL, a production-oriented fork of SQLite, and the newer Turso Database engine. Turso’s libSQL documentation says libSQL keeps SQLite’s file format, API, and backwards compatibility, while Turso Database is a ground-up rewrite designed for concurrent writes and async I/O. The docs recommend libSQL for mission-critical workloads that need a battle-tested foundation today. That maturity distinction should be part of a 2026 decision.

Turso’s point-in-time recovery documentation describes restores as new databases. The current windows are 24 hours on Free, 10 days on Developer, 30 days on Scaler, and 90 days on Pro. At the 2 August 2026 recheck, Free carried 5 GB of storage and 100 databases, and the Developer plan cost $4.99 per month with 9 GB. The application must switch to the restored database and use an appropriate token.

Best for

Architectures that are genuinely SQLite-compatible, local-first, embedded, or database-per-tenant. If you want one small database per customer, this is the option built for it.

Where it falls short

PostgreSQL extensions, types, functions, RLS policies, and Supabase services do not map directly to SQLite-compatible libSQL. Turso is a poor escape hatch for a relational Supabase app whose real issue is one slow query. Restoring to a new database also means the application has to be told where to point, which is a deployment step, not a dashboard toggle.

What you still have to build

Authentication, object storage, and any server functions. Authorization lives in your application on top of database tokens, so the ownership check that RLS used to enforce becomes application code you write and test.

Open-source, source-available, and self-hostable options

Four names dominate the self-hosted half of this search: Appwrite, PocketBase, Nhost, and Directus. The first three are open source. Directus v12 uses a source-available license that converts each release to GPLv3 after four years. They answer a different question from Neon or Firebase. The question they answer is how much of the stack you want to own, rather than which managed database to rent.

Appwrite

Appwrite is the closest like-for-like bundle to Supabase: auth, databases, storage, functions, messaging, and realtime in one platform, available as Appwrite Cloud or self-hosted on any operating system that runs the Docker CLI. The source is public under a BSD 3-Clause license. Current Appwrite Cloud offers TablesDB on Serverless and five database engines on Dedicated, including native PostgreSQL and MySQL.

Appwrite Cloud’s pricing page lists a Free plan with 5 GB bandwidth, 2 GB storage, 750K function executions, and 75K monthly active users, capped at one database, one bucket, and two functions per project, two projects total, with projects paused after one week of inactivity. Pro starts at $25 per month with 2 TB bandwidth, 150 GB storage, 3.5M executions, 200K monthly active users, and daily backups retained for seven days. Appwrite’s own self-hosting docs are unusually honest about the tradeoff: self-hosting often costs more once you count time and expertise.

Best for: a project that wants the whole Supabase-shaped bundle with a credible exit onto your own hardware.

Where it falls short: the migration depends on the database engine and hosting tier you choose. TablesDB has relational-style tables but does not preserve PostgreSQL-specific SQL, RLS helpers, or extensions. Native PostgreSQL is a Dedicated option, so it has a different cost and operating model from the default Serverless path. Permissions and SDK calls still need a separate migration.

PocketBase

PocketBase is one executable. Its documentation describes it as an open source backend with an embedded SQLite database, realtime subscriptions, built-in auth management, a dashboard UI, and a REST-ish API. You download a prebuilt binary of roughly 11 to 12 MB, run ./pocketbase serve, and that is the backend. Backups are a built-in snapshot of the pb_data directory as a ZIP archive, stored locally or in S3-compatible storage.

The caveat comes from the project itself. PocketBase has not reached v1.0.0, full backward compatibility is not guaranteed before it does, and the docs advise against production-critical applications unless you accept possible migration steps between versions.

Best for: a small app with one server, one founder, and a genuine preference for owning the box.

Where it falls short: one binary means one machine. There is no managed cloud, no horizontal scale story, and PostgreSQL features do not survive the move to SQLite.

Nhost

Nhost is the tightest structural clone of Supabase here, with one substitution: the API is Hasura GraphQL instead of PostgREST. The stack is PostgreSQL, Hasura, auth, storage, and serverless functions, and it is open source and self-hostable.

Its pricing page lists a free Starter plan with a 1 GB database, 1 GB storage, and 5 GB egress, limited to one active project and paused after one week of inactivity. Pro starts at $25 per month and Team at $599.

Best for: a team that wants Supabase’s shape but prefers GraphQL subscriptions and Hasura’s permission model to PostgREST and RLS.

Where it falls short: the free tier idles out on the same one-week clock that sends people looking for a Supabase alternative in the first place, and every generated client call changes from REST to GraphQL.

Directus

Directus is less a backend to migrate into and more a layer to put on top of one. It wraps a SQL database you already run, maps collections and fields directly to the schema already there, and adds REST and GraphQL APIs, a file library, realtime data, and access control down to the field level.

Directus v12 is source-available under the Directus Sustainable Cloud License, not currently open source. Each release converts to GPLv3 four years after publication. Its SDK remains MIT-licensed.

Its pricing page lists a free Core plan with 3 user seats, 25 collections, and 5 flows; Team at $499 per month billed annually or $599 rolling; and an Open Innovation Grant that is free on self-hosted for organizations under $5M in revenue with fewer than 50 employees. Self-hosting is available on every plan.

Best for: an app that already has a PostgreSQL database it is happy with and needs an admin UI, roles, and an API rather than a new platform.

Where it falls short: Directus users and roles are built for the people managing data, so a consumer app with a large end-user base usually still pairs it with a dedicated auth provider. The free plan’s seat, collection, and flow caps also bite early.

Managed PostgreSQL: own the backend around the database

Railway, Render, AWS RDS, and other managed PostgreSQL services can preserve the SQL layer. They differ in availability, connection limits, network topology, maintenance windows, backups, restore behavior, and price, so “plain Postgres” is a category rather than one comparable plan. At the 17 August 2026 recheck, Render’s smallest paid Postgres configuration was $6 per month for compute plus $0.30 per month for its initial 1 GB of separately billed storage. AWS RDS pricing depends on the region, engine, storage, term, and billing model. A free Render Postgres is deleted 30 days after creation plus a 14-day grace period, data included.

Best for

An app that already has a backend enforcing authorization and used Supabase mainly for PostgreSQL. If browser clients never talk to the database directly, this is the shortest move on the page.

Where it falls short

It creates more work when browser clients currently rely on Supabase’s Data API, Auth, Storage, or Realtime. In that case, database portability is only one part of backend portability, and the missing four services are the actual project.

What you still have to build

Avoid calling this option “no lock-in.” PostgreSQL improves data and query portability, while IAM, networking, read replicas, observability, backup operations, and provider-specific extensions can still couple the application to a host. Vendor lock-in is the sum of everything around the database engine that you did not write, rather than a property of the engine itself.

Replacing one Supabase service instead of all of them

Most of the pain in this comparison comes from treating Supabase as one thing. It is a database plus four services. Replacing one and keeping the rest is usually cheaper, faster, and easier to roll back than replacing all five.

Auth only

Clerk, Auth0, WorkOS, SuperTokens, Keycloak, and Better Auth all replace Supabase Auth without touching the database. Keep PostgreSQL and its RLS mechanism. Then replace Supabase auth helpers and roles, and change what mints the JWT your policies read.

Four things do not transfer automatically. Password hashes are portable only if the destination accepts the source’s hashing algorithm. MFA factors usually are not. OAuth identities are tied to provider client IDs, so re-consent is often required. Live sessions end at cutover, which means every user is logged out on the day you switch. Confirm each one with the destination before you announce a date.

One more trap: RLS policies read a claim out of the JWT. If the new provider issues tokens with a different claim shape, every policy that depends on it needs updating. That is a schema change, not a configuration change.

Storage only

S3, Cloudflare R2, and Backblaze B2 replace Supabase Storage. Copying the bytes is the easy part. The rework is in signed-URL generation and expiry, per-object access policy (Supabase Storage policies are RLS on a table, and S3-family policies are not), any image transformation you relied on, and every stored path recorded in your database rows.

Realtime only

Realtime is the one service where the honest answer is often to drop it. Ask whether the app needs server push or just fresher data. Polling on an interval, or invalidating a query after a mutation, covers a large share of what Supabase Realtime gets used for in AI-built apps. If you do need push, Ably, Pusher, or a WebSocket service you run yourself are the usual replacements, and each of them moves the authorization check into your own code.

Rule out the ordinary causes first. Supabase Realtime being slow or not firing at all is usually a subscription that never connected, a table that was never toggled on under the supabase_realtime publication, or an RLS policy that hides the row from the listener, since Realtime authorizes every event against each subscriber. None of those three follows you to a new provider.

Free tiers and the first bill

The most common version of this question is two practical ones rather than an architectural one: what does this cost to start, and what happens if I stop looking at it for a month?

Convex is missing from this table on purpose: its plan limits were not rechecked at this pass, so read its pricing page directly rather than trusting a number here.

Two patterns are worth naming. First, the one-week idle pause that sends people looking for a Supabase alternative also exists on Appwrite and Nhost, so that specific complaint is not solved by either of them. Second, the cheapest first bill is not the cheapest first year. A $5 single-node cluster and a $25 organization with daily backups buy very different failure tolerance, and the difference shows up on exactly one day.

What a backend migration will not fix

Across the fixed AxonBuild cohort of 21 third-party AI-built apps audited in June and July 2026, 17 recorded errors nowhere and at least 17 had no deploy gate. Nine had an RLS gap, with cross-user access confirmed in 7. These are sample findings across several builders, not failure rates for Supabase or any alternative on this page.

The mechanisms travel:

• A Firestore rule can stop at request.auth != null without checking document ownership.
• A Convex function can trust a caller-supplied user ID.
• A PostgreSQL policy can grant every authenticated user access to every tenant row.
• An Appwrite collection permission can grant the users role read access to every document.
• A server route can use an administrator credential before checking the caller.

Changing the database does not supply the missing ownership check, error alert, deploy gate, or tested restore. Those controls have to be built again on the new stack and proven with an explicit test.

Every backend on this list will happily serve one customer another customer’s rows, if that is what your code asks it for.

How to choose

A migration sequence that preserves a way back

The sequence below is written for a move off Supabase, and it runs unchanged in the other direction. Migrating to Supabase from Firebase, from a managed PostgreSQL host, from a local database, or from AWS is the same inventory read backwards: schema and rows first, then auth identities, then stored files, then the authorization retest. Read “destination” as whichever side you are moving toward.

1. 01 Inventory PostgreSQL schema, extensions, functions, triggers, RLS, auth identities, Storage objects, Realtime subscriptions, Edge Functions, webhooks, cron jobs, and secrets. Give each surface a destination or a written retirement decision.
2. 02 Build the destination schema through version-controlled migrations. Record every type, extension, or policy that requires a rewrite instead of assuming the import preserved its meaning.
3. 03 Export schema and data separately, import into an isolated destination, and compare table counts plus application-level invariants such as paid accounts with active entitlements.
4. 04 Migrate authentication with a provider-supported flow. Determine whether password hashes, MFA factors, OAuth identities, sessions, and reset links are portable before announcing a cutover.
5. 05 Copy object storage separately and verify object counts, metadata, access policy, and a representative download. A normal PostgreSQL dump does not contain the file bytes.
6. 06 Run authorization and side-effect tests on the destination. Cover two-account isolation, privileged functions, webhooks, background jobs, email, payments, and costly AI actions.
7. 07 Choose a cutover strategy for writes. Pause writes, dual-write with reconciliation, or replicate changes; never rely on a final dump while the source is still accepting untracked writes.
8. 08 Keep the source read-only and recoverable through an agreed rollback window. Restore a destination backup before deleting the old project or its credentials.

The commands behind step three

For a PostgreSQL destination, the export and import is a short sequence, run in this order.

# 1. Schema first, so you can read what actually moved before any data lands.
pg_dump --schema-only --no-owner --no-privileges "$SOURCE_URL" > schema.sql
psql "$DEST_URL" -v ON_ERROR_STOP=1 -f schema.sql || exit 1
# Read the imported schema (\dt and \d on the tables you care about) before going on.

# 2. Then the rows, separately and only after the schema import exited clean, so a schema failure is never a data failure.
pg_dump --data-only --no-owner "$SOURCE_URL" > data.sql
psql "$DEST_URL" -v ON_ERROR_STOP=1 -f data.sql || exit 1

# 3. Compare per-table counts on both sides before trusting the import.
psql "$SOURCE_URL" -c "select relname, n_live_tup from pg_stat_user_tables order by relname;"
psql "$DEST_URL"   -c "select relname, n_live_tup from pg_stat_user_tables order by relname;"

n_live_tup is an estimate. Use it to spot a table that arrived empty, then run exact count(*) queries on the tables holding money, entitlements, and identity.

What the dump does not contain: Storage object bytes, Edge Function code, project secrets, cron schedules, webhook registrations, and auth users in a form the destination will necessarily accept. Each of those is a separate migration with its own verification step.

If your app was built with Lovable, Base44, Bolt, or Claude Code

These tools do not share one backend default. Lovable Cloud has a built-in backend based on Supabase’s open-source foundation, while a separate Supabase integration remains optional. Base44 stores entities in its own MongoDB-compatible document database. Bolt Cloud provides a built-in database and also supports Supabase. Claude Code is a general coding agent and chooses no backend for the project. Inspect what the current project actually uses before estimating a migration.

If the project uses Supabase, generated client code may call the Supabase JS SDK straight from the browser. Calls like supabase.from('profiles').select() can be scattered across components rather than hidden behind one data layer. Swapping the backend means rewriting those call sites, not changing one connection string. Search the repository for supabase. before you estimate anything.

For a Supabase-backed project, the RLS policies are part of the security model. PostgreSQL policy mechanics can move to Neon, PlanetScale Postgres, or managed PostgreSQL. Supabase helpers, mapped roles, and JWT claims do not move just because the destination speaks PostgreSQL. Firestore, Convex, Appwrite, and PocketBase use different authorization models, so those rules need rewriting and a second-account test.

If the reason for leaving is a free-tier pause or a bill, fix that inside Supabase first. If the reason is that the generated app has an authorization hole, moving it will move the hole.

Moving off Lovable Cloud shows why a backend export extends beyond database rows. The Lovable database export guide covers the restore-and-verify side of the move. The same inventory applies to Supabase even when the destination also runs PostgreSQL.

Common questions about Supabase alternatives

Which Supabase alternatives are worth considering?

The Supabase alternatives worth considering depend on which part of Supabase you need to replace: Neon and PlanetScale keep PostgreSQL, Firebase and Convex replace the data-access model, Appwrite and Nhost replace the whole bundle, PocketBase and Directus let you own the box, and Turso moves the app toward SQLite. Because Supabase bundles a database, auth, storage, realtime and functions, one swap is really five swaps, which is why the comparison below is organised by service.

What is the best Supabase alternative in 2026?

Neon is the closest general alternative for a PostgreSQL-first app. Firebase fits document-oriented mobile and web apps, Convex fits a reactive TypeScript data layer, Turso fits SQLite-compatible and local-data architectures, and Appwrite is the closest open-source replacement for the whole Supabase bundle. An existing app that uses several Supabase services will often spend less effort fixing the measured issue and staying.

Is there a free Supabase alternative?

Yes, several. At the August 2026 check, Neon’s free plan included 0.5 GB of storage and 100 compute-unit-hours per project per month, Turso’s included 5 GB and 100 databases, Appwrite’s included 2 GB of storage and 75,000 monthly active users, and Nhost’s free Starter included a 1 GB database. Appwrite and Nhost both pause free projects after a week of inactivity, which is the same behavior that sends people looking for a Supabase alternative, and PlanetScale has no free tier at all.

What is the best open-source Supabase alternative?

Appwrite is the closest open-source replacement for the full bundle, since it ships auth, databases, storage, functions, and realtime and self-hosts with Docker. PocketBase is the smallest option, a single binary with an embedded SQLite database, and Nhost is the closest structural clone if you prefer a Hasura GraphQL API to PostgREST. Directus is the odd one out: it wraps a SQL database you already run rather than replacing it.

Can I self-host Supabase instead of leaving?

Yes. Supabase documents Docker as the recommended self-hosting path, and the client SDKs, Data API, and RLS model stay the same, so your application code does not change. What changes is that server provisioning, security hardening, PostgreSQL maintenance, high availability, backups, and monitoring become yours, and Supabase says branching, managed backups, point-in-time recovery, and analytics are unavailable in a self-hosted configuration.

Is Firebase better than Supabase?

Neither is better in general; they answer different questions. Firebase wins when the product is mobile-first, needs offline sync, and fits a document model with per-operation billing. Supabase wins when the data is relational, when you want SQL and row-level security, and when you want the option to run the same stack on your own server.

Which alternative is easiest to migrate to?

A managed PostgreSQL provider, Neon, or PlanetScale Postgres preserves the largest share of PostgreSQL schema and queries. Supabase Auth, Storage, Realtime, Edge Functions, and Data API behavior remain separate work in every case. The easiest destination is the one whose unchanged surfaces you have actually counted.

How long does a Supabase migration take?

Ask the question per surface, not per project. A PostgreSQL-to-PostgreSQL move of schema and rows is often an afternoon, but auth identities, storage objects, realtime subscriptions, edge functions, cron jobs, and webhooks are five or six separate migrations stacked on top of it. Budget by counting those surfaces, then add the authorization retest, which is the step teams skip and regret.

Which alternative has the best backups?

There is no useful winner without a recovery objective. Compare retention, restore granularity, restore destination, Storage-file coverage, regional failure assumptions, and the cost of keeping the required window. Then restore one backup. Supabase backup coverage by plan is the baseline for the current system.

Should I leave Supabase because an RLS policy is wrong?

Usually no. Correct and test the policy first. Every alternative has an authorization boundary, and a migration can reproduce the same ownership mistake in a new language. Why Supabase is popular lists the bundled decisions you would be taking back into the application.

A migration earns its cost when the destination resolves a named constraint that the current system cannot meet at an acceptable price or complexity. If the reason cannot be written as a test, the comparison is still research rather than a migration plan.