Move off Supabase, keep the client

# Keep the client. Move the rest.

The usual reason a project stays on a platform is the sign-in code: every page uses the client, and rewriting it is a month. Lathe's Auth engine is built on the open-source server behind Supabase Auth, so supabase-js talks to it unchanged. The database moves with pg_dump, the users move with their identities, and the front end changes a URL and a key. [Start Free - $0 ](https://app.lathe.live/login)[From $15 a month → ](https://lathe.live/pricing)

## The move, in order. 1. The database pg_dump from the platform, pg_restore into the Lathe instance over the direct port. Row-level security, roles and extensions are Postgres and come along. 2. Sign-in Switch the Auth engine on; it needs Postgres and the apps engine on the same machine. Its users live in an auth schema of the same layout, so users and their identities move table to table. Tell us before the run and we will help. 3. The front end createClient with the new URL and the anon key from the instance page. signInWithOtp, signInWithOAuth, getSession and the rest are unchanged. 4. The providers Register the new callback address with GitHub, Google or whichever providers you use, and put the client ids and secrets in the engine's settings. What does not come Edge functions and realtime are platform services: an app on the machine takes the place of functions, and realtime needs a home of its own. Files move to the object storage engine's S3-compatible buckets, over the S3 API rather than supabase-js's storage client. What you gain One flat price for the database, the sign-in and the app, with nothing per user or per gigabyte. Paid plans do not sleep when idle.

## Good for

- An app built on supabase-js that only ever used Postgres and auth
- A project whose bill grew with its users
- A team that wants its users in a database it can query
- A move that has to happen without a front-end rewrite

## Questions

**Do my users have to reset their passwords? **

No. Password hashes are standard and move with the users, so nobody is asked to reset.

**Does auth.uid() still work? **

The function reads a session variable that the platform's API layer set from the token. Without that layer your app sets it, one SET per request, or checks the token in code against the published keys.

**Is it the same software? **

Built on the same open-source server, pinned by version and run for you beside your database. Lathe sells it as Auth; the settings are ours, the protocol is theirs.

**Can I keep sign-in on Supabase and move only the database? **

Yes. The database moves the same way and your app keeps talking to Supabase for sign-in; nothing on the machine needs the Auth engine on.

Every number on this page comes from the [pricing page ](https://lathe.live/pricing)'s facts. [Previous Supabase alternative: one machine, one flat bill ](https://docs.lathe.live/guides/supabase-alternative)[Next PostgreSQL vs Supabase: what the difference is ](https://docs.lathe.live/guides/postgres-vs-supabase)

## Related

- [Sign-in for your app with no price per user ](https://docs.lathe.live/guides/auth-flat-price)

Managed sign-in with the users in your own Postgres: email links, OAuth, MFA, sessions, in the flat plan price. Users are never a line on the bill.
- [Move a Postgres database with pg_dump and pg_restore ](https://docs.lathe.live/guides/migrate-postgres)

Moving a PostgreSQL database between providers in three commands: dump, restore, switch the connection string. What to check, and how to keep downtime short.

[All guides ](https://docs.lathe.live/guides)

## The database and the sign-in, off the platform, from $15 a month.

Live about 5 minutes on average after creation on Free or checkout on a paid plan. Paid plans: cancel any time. [Start Free - $0 ](https://app.lathe.live/login)
