A Supabase alternative your existing supabase-js code already talks to

Why teams look for a Supabase alternative

Most teams that search for an alternative are not unhappy with the Supabase API. They like supabase-js, row level security and the auth model. What they want to change is around it: per-project cost once an app has staging and preview databases, free projects that are paused after a period of inactivity, and database branches that need extra setup.

Scribase keeps the API and changes those three things. That is the whole pitch, so the rest of this page is a list of what is the same, what is different, and what is not finished yet.

What stays the same: the client and the data model

Your app keeps calling createClient(url, key). The tables, policies, auth.users, storage.objects and realtime channels are the same Postgres objects, so policy code such as auth.uid() = user_id runs unchanged.

import { createClient } from '@supabase/supabase-js'

// Before: https://<ref>.supabase.co
// After:  the Project URL and publishable key from the Scribase console
export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
)

What is different

• Price: $25 per project per month, billed for the most projects you had at once in the month. Staging and preview environments are part of the project.
• Idle projects scale to zero and wake on the next request. They are not paused, and nobody has to restore them from a dashboard.
• Branching is copy-on-write: a branch gets its own URL and keys and carries the parent rows without copying them first. You can branch from a past point in time, mask columns in a branch, and give a branch an expiry.
• Your coding agent can set the backend up: the CLI and MCP server create projects, run migrations and open branches with scoped tokens.
• Export is a button: a bundle with the schema, data, auth users and storage objects, so leaving is as easy as arriving.

What does not work yet

We publish the gaps instead of hiding them. As of the last check:

• Phone and SMS one-time codes: the allow list works, the managed SMS sender is not switched on yet.
• Direct Postgres connections from the internet (ports 5432 and 6543, for psql or pg_restore): not open yet. Migrations, the console SQL editor and the HTTP serverless driver work today.
• Read replicas and foreign data wrappers to remote servers: built, not yet proven on the hosted service.

How to move a Supabase project

1. Step 1

   Dry run

   The importer reads your project and prints the tables, rows, users, objects and bytes it would move, plus any policy that admits every row. It writes nothing.

   scribase import supabase --project-ref <your-ref> \
     --org acme --project app --env production \
     --connection-string "$SOURCE_DB_URL" --service-key "$SOURCE_SERVICE_KEY" --dry-run

2. Step 2

   Run it and read the report

   Schema, auth users with their bcrypt hashes, data, policies and storage move in order. The run ends with row counts and checksums for every table, so you can see that nothing was lost.

3. Step 3

   Swap two environment variables

   Point SUPABASE_URL and SUPABASE_ANON_KEY at the new project. Users keep their passwords.