Skip to main content

Supabase vendor-lock

· 5 min read
Serhii Hrekov
Serhii Hrekov
software engineer, creator, artist, programmer, projects founder

There is minimal vendor lock-in with Supabase. The platform is designed to be as open as possible, leveraging established, open-source technologies. This makes it relatively easy to migrate away from their managed service if needed.

Is there vendor lock-in with Supabase?​

Supabase is built on a foundation of popular open-source tools, with PostgreSQL at its core. This design philosophy is key to minimizing vendor lock-in. All of your data is stored in a standard PostgreSQL database, and your schemas are defined using standard SQL.

While Supabase provides a powerful suite of services on top of Postgres (like Auth, Storage, and Realtime), these components are all open-source as well. This means you have the option to self-host the entire Supabase stack if you want to. The most significant aspect of this is that your core database and its schema remain fully portable.

The areas where you might encounter some "stickiness" are with features that are highly integrated into the Supabase ecosystem, such as:

  • Supabase Auth: The user data and metadata for Supabase Auth are stored in the database's auth schema. While this data is accessible and can be exported, migrating the full authentication logic (like OAuth providers and magic links) to another service will require some effort.
  • Edge Functions: Supabase Edge Functions use the Deno runtime. While the code itself is standard TypeScript, the deployment and secrets management are specific to the Supabase platform.
  • Database Webhooks: These use the pg_net extension to make HTTP requests. While the concept is standard, the implementation is tied to Supabase.

However, because these features are built on open standards and are often available in the self-hosted Supabase stack, the path to migrating is clearer than with a closed-source platform.

Can I export my entire Supabase database and run it locally?​

Yes, you can export your entire Supabase database, including both the schema and the data, and run it locally without Supabase's managed services. This is a core part of Supabase's open-source ethos.

The Process​

  1. Exporting the Schema: The best way to manage and export your schema is by using the Supabase CLI and its migrations system. You can use supabase db pull to generate a migration file that represents your remote database's schema. This gives you a complete, version-controlled record of your entire database structure, including tables, functions, and RLS policies.
  2. Exporting the Data: You can use standard PostgreSQL tools like pg_dump to create a backup of your data. The Supabase Dashboard provides a pg_dump command you can copy and paste to dump your database. You will need to filter out Supabase's internal schemas (supabase, auth, storage, etc.) to get a clean dump of your application's data.
  3. Running Locally: Once you have your migrations and a data dump, you can use the Supabase CLI to run a local instance of the entire Supabase stack (Postgres, Auth, Storage) in Docker containers. You would then apply your migrations and restore your data dump to the local instance. This creates a fully functional, local replica of your production environment, giving you complete control and a clear path to self-hosting or migrating to another provider.

This video shows how to export a Supabase table to a CSV file, which can be useful for data migration. How to import and export CSV from a Supabase database.