Supabase

Supabase is an application backend built around a standard PostgreSQL database. It is usually described as an open-source Firebase alternative, and the comparison is useful up to a point: both give you a database, authentication, file storage, serverless functions and realtime updates without operating infrastructure. The important difference is what sits underneath. Firebase gives you proprietary document datastores with their own query model and no way to take the engine with you. Supabase gives you Postgres, with SQL, relations, joins, stored procedures, triggers, foreign keys and the entire extension ecosystem, and the whole platform is open source so you can run it on your own servers.

The database is the product. When you create a Supabase project you get a real Postgres instance, accessible with any Postgres client, psql, pgAdmin, an ORM like Prisma or Drizzle, or the platform's own Studio dashboard. Tables have proper schemas and constraints. You can write SQL migrations, use views and materialised views, define functions in plpgsql, and install extensions. pgvector is available for embeddings and semantic search, PostGIS for geospatial queries, pg_cron for scheduled jobs, and pg_net for outbound HTTP calls from inside the database. For a team that already knows SQL, this removes the learning curve that a proprietary datastore imposes, and it removes the migration cliff you hit when an application outgrows a document store.

On top of Postgres, Supabase generates APIs automatically. PostgREST inspects the schema and exposes a REST endpoint for every table and view, and a GraphQL layer is also available. Client libraries for JavaScript, TypeScript, Flutter, Swift, Kotlin, Python and others wrap these endpoints with a query builder, so reading and writing data from an app takes a few lines rather than a backend service. This is genuinely useful for prototypes and internal tools, where writing CRUD endpoints is pure overhead.

Authentication is handled by GoTrue, supporting email and password with confirmation flows, magic links, phone and SMS one-time codes, passkeys, and OAuth with Google, Apple, GitHub, Microsoft and many other providers. Sessions are JWTs. The critical piece is how authorisation works: Postgres Row Level Security policies define, in SQL, which rows a given role can read or write. Because the rules live in the database, they apply no matter which client connects, and there is no application layer that can accidentally bypass them. This is a strong security model, and also a demanding one: writing correct RLS policies takes thought, and a badly written policy is a data leak.

Storage provides object storage with an S3-like API for user uploads such as images, video and documents, with access controlled by the same RLS policy system, plus on-the-fly image transformation and resizing. Edge Functions run TypeScript and JavaScript on Deno at the edge for logic that should not live in the database or the client, such as calling third-party APIs with secrets, handling webhooks or orchestrating multi-service workflows. Realtime broadcasts database changes over WebSockets so clients can subscribe to inserts, updates and deletes on a table or filtered query, and there are also presence and broadcast channels for collaborative features.

Comparisons are unavoidable. Firebase is the incumbent, backed by Google, with mature mobile SDKs, deep analytics and a huge body of documentation, but it locks you into NoSQL document stores and Cloud Firestore pricing that scales with reads and writes. Supabase gives you relational integrity, SQL and portability at the cost of a younger ecosystem and less mobile-specific tooling. Appwrite is another open-source backend-as-a-service with a broader set of features out of the box, including functions in many languages, but with a less database-centric design. Neon and PlanetScale are serverless Postgres or MySQL platforms that focus purely on the database and leave auth and storage to you. PocketBase and Nhost are lighter self-hostable options. If you already run Postgres somewhere and only need auth, you may not need Supabase at all. The honest positioning is that Supabase is the strongest choice when you want a managed, batteries-included backend whose core is a database you fully understand and can take with you.

Pricing is usage-based with a free entry point. The free plan allows a small number of projects, limited database size, storage and monthly active users, and pauses projects that are inactive for a period, which makes it suitable for prototypes and hobby work but not for anything that must stay up. The Pro plan has a fixed monthly base fee per project plus usage charges for compute, database size, storage, egress, function invocations and additional monthly active users. Team plans add collaboration features and higher limits, and Enterprise agreements add custom compute, dedicated support, security review and contractual terms. Because the bill is driven by usage, the costs that surprise people are egress, compute sizing and monthly active users rather than the base fee. Current figures are published on the vendor pricing page and change often enough to warrant checking before you forecast.

The limitations need to be stated clearly. Self-hosting the full stack is possible but it is not trivial: the platform is a composition of several services, and operating them in production with backups, monitoring and upgrades is real work, which is why many teams use the hosted service and keep self-hosting as a contingency. The free plan's project pausing behaviour is a common complaint for anything beyond a demo. RLS policies must be written carefully, and debugging permission errors is harder than debugging application code. Cold starts and compute sizing matter for spiky workloads. The ecosystem of tutorials and third-party integrations is smaller than Firebase's, particularly for native mobile. There is no built-in equivalent to Firebase's Crashlytics, Remote Config or A/B testing, so those come from elsewhere. And because you get raw Postgres, you can write queries and schema that perform badly; the platform does not protect you from your own SQL.

Supabase fits startups and small teams building web or mobile products who want a relational database, auth and storage assembled quickly without hiring a platform engineer. It fits products where data relationships matter, such as marketplaces, dashboards, internal tools and any application with real reporting needs. It fits teams that value portability and want an exit path from the vendor. It also fits AI applications that need vector storage next to relational data. It does not fit teams building offline-first mobile apps where Firebase's client SDK maturity is decisive, organisations that need a fully managed enterprise database with a support contract from a hyperscaler, or projects so small that a single SQLite file would do.

In the closing comparison, choose Supabase when SQL, data integrity and open source matter to you and you want managed auth and storage on top. Choose Firebase when you are building a mobile-first consumer app, want Google's ecosystem and analytics, and are comfortable with a document model. Choose Neon or a plain managed Postgres when all you need is a database. Choose Appwrite when you want an open-source backend with broader language support for functions and less emphasis on the database. For a typical web product in the current market, Supabase offers the best balance of speed, control and long-term portability of the group.