Coming from Supabase to Encore

Supabase combines Postgres with generated data APIs, authentication, object storage, Realtime, and Edge Functions. Moving to Encore means defining the backend operations your clients use with Encore's TypeScript or Go SDK, with databases, buckets, and other supported infrastructure declared alongside them. These declarations form the application model Encore uses for local development and deployment.

You do not need to migrate every Supabase service at once. An Encore application can connect to a Supabase project through its normal APIs or Postgres connection string while you move individual workloads.

How the concepts map

Supabase	Encore
Postgres database and SQL migrations	A SQL database and migration files
REST Data API served by PostgREST	Explicit, type-safe API endpoints that query the database
Row Level Security (RLS) for Data API access	Authorization in API handlers and database queries; Postgres RLS can still be used when required
Supabase Auth	Keep Supabase Auth as an external service, or use another identity provider with an Encore authentication handler
Storage Files buckets and Storage policies	Object storage buckets, with access controlled through Encore APIs
Realtime database changes, Broadcast, and Presence	No single equivalent; use streaming APIs, Pub/Sub, or keep Supabase Realtime
Edge Functions	Encore API endpoints, Pub/Sub subscribers, or cron jobs, depending on how the function is invoked
Project secrets	Encore secrets, with values set per environment
Supabase dashboard logs	Encore platform traces, metrics, and structured logs

These primitives are declared in application code using TypeScript or Go.

Choose what to move

Start by recording which Supabase features the application uses directly from a browser or mobile client. Calls to the Data API, Auth, Storage, and Realtime often share Supabase access tokens and RLS or Storage policies. Moving one of those features may therefore require a new backend endpoint or a change to the client.

For each feature, choose one of three approaches:

keep it in Supabase and call it from Encore as an external dependency
move it to an Encore primitive or application service
replace it with another provider and validate its credentials in an Encore authentication handler

The general PaaS migration guide covers Encore's deployment models and the migration sequence shared by hosted platforms.

Database and generated APIs

A Supabase project uses Postgres, so its tables, indexes, constraints, functions, and data can be transferred with standard Postgres tools. Supabase documents which connection type to use for pg_dump and other native commands. Encore does not directly import a Supabase-hosted database as a managed resource.

To move the database:

Export the application schema and data. Exclude Supabase-managed schemas that belong to services you are not migrating.
Turn the application schema into an initial Encore migration and add the SQL database declaration.
Test the migrations against a new local database with encore run.
Create the target database from those migrations, then load the exported data without recreating the schema.
Check Postgres versions, extensions, roles, ownership, sequences, and functions before cutover.
Stop writes or replicate changes while performing the final data transfer, then switch the application to the new environment.

Supabase-managed schemas such as auth and storage belong to their respective Supabase services. Do not treat them as application tables unless the replacement service explicitly supports that data and schema.

Encore does not generate a CRUD API from the database schema. Supabase no longer exposes one automatically either: since May 2026 new projects require tables to be granted to the API roles explicitly, and that becomes the default for existing projects on 30 October 2026, so how much of the Data API there is to move depends on when the project was created. Define the operations your clients need as Encore endpoints and move queries behind those endpoints. Generated TypeScript clients can provide typed access from a frontend.

If clients currently access Supabase directly, run the new API alongside the Data API and migrate one operation at a time. Keep RLS policies in place for traffic that still reaches PostgREST. For the new Encore endpoints, reproduce the required authorization checks in application code or SQL; do not assume existing RLS policies and backend credentials enforce the same access path.

Authentication

Encore provides the authentication hook used by its API gateway, but it does not provide a hosted user directory or sign-in UI. You can keep Supabase Auth during and after the migration by validating access tokens according to Supabase's JWT guidance in an Encore authentication handler. The existing client sign-in and session-refresh flow can then remain in place while Encore protects its own endpoints.

If you replace Supabase Auth, plan the migration with the destination identity provider. Supabase stores user records in the auth schema, but copying those tables is not a supported substitute for importing users through the destination provider. Check how password hashes, social identities, MFA factors, email verification, custom claims, and active sessions are handled. A staged migration may require users to sign in again or reset their passwords.

Keep user identifiers stable where possible. If identifiers change, migrate foreign keys and application records that refer to auth.users.id before switching authentication providers.

Storage

Encore object storage provides bucket operations and signed URLs, but it does not reproduce Supabase Storage policies or its database metadata.

To move a bucket:

Declare the target object storage bucket.
Copy the objects with an object-storage transfer tool, preserving object paths and required metadata. This applies to Files buckets. Supabase Analytics buckets (Apache Iceberg) and Vector buckets have no Encore equivalent and need a separate destination.
Replace Supabase Storage client calls and URLs with Encore API calls or URLs generated for the new bucket.
Implement access checks in the Encore endpoints that issue signed URLs or read and write objects.
Update stored public URLs, cache rules, CORS settings, and upload limits where applicable.

Existing signed URLs are tied to Supabase and should not be expected to work after the objects move. Keep the old bucket available until clients and persisted URLs have been updated.

Edge Functions and background work

Move HTTP Edge Functions to Encore API endpoints. A function invoked by a webhook can usually become a public raw endpoint, while authenticated application operations can use typed endpoints.

Use Pub/Sub subscribers for asynchronous work and cron jobs for schedules. Database webhooks and triggers need separate treatment: publish an event from the application when Encore owns every write path, or retain a database-level integration when other systems can still modify the table. Confirm retry, ordering, timeout, and idempotency behavior rather than assuming it matches the Edge Function deployment.

Supabase Edge Functions run in a Deno-compatible runtime. Encore TypeScript services run on Node.js, so review Deno-specific APIs, imports, permissions, and runtime assumptions during the rewrite.

Realtime

Supabase Realtime covers three different capabilities: Postgres change subscriptions, Broadcast channels, and Presence. Encore does not provide a drop-in replacement for that combined service.

Use streaming APIs (TypeScript) for application-managed WebSocket connections.
Use Pub/Sub for events exchanged between backend services. Pub/Sub is not a browser subscription API by itself.
Keep Supabase Realtime when clients still need Postgres change feeds, Broadcast, or Presence, and connect it to the remaining Supabase database.

When replacing database change subscriptions, define the events the client actually needs instead of exposing every row change. Account for reconnects, missed messages, authorization, and the initial data load as part of the client protocol.

Run Supabase and Encore together

Store any secret API key, legacy service_role key, or database connection string as an Encore secret. Use elevated keys only in backend code and only for operations that need to bypass RLS. For user-scoped Supabase requests, pass the user's access token through a client initialized with a publishable key instead.

An incremental migration can follow this order:

Deploy an Encore service without changing the existing Supabase clients.
Validate Supabase tokens in Encore and move selected business operations behind Encore APIs.
Move Edge Functions and background work whose data dependencies are understood.
Decide whether to retain or replace Auth, Storage, and Realtime independently.
Transfer the Postgres database after all remaining direct client access and replication requirements are accounted for.
Switch traffic, monitor both systems, and remove Supabase resources only after data and client behavior have been verified.

Avoid concurrent writes to old and new databases unless you have designed conflict handling and reconciliation. The required downtime depends on the transfer method and the application's write volume.

Supabase services kept during the migration remain in the Supabase project's provisioning and billing lifecycle. Encore secrets and external-dependency code provide the connection; they do not transfer ownership of those services to Encore.

Before cutover

Compare row counts and application-level invariants after the final database copy.
Exercise sign-in, token refresh, authorization, and account-recovery flows.
Verify object counts, metadata, access checks, and persisted URLs.
Test Realtime reconnect behavior and delivery after a deployment or network interruption.
Check webhook retries, scheduled jobs, and idempotency.
Update client configuration, CORS, custom domains, and callback URLs.
Keep a rollback path until the new deployment has handled production traffic successfully.

Next steps

Follow the Quickstart guide.
Read Migrating an existing system to Encore for service-by-service adoption patterns.
Review Deploying applications before choosing a production environment.