From c987e9159f8d51cdcf7adee668579dd559024a8b Mon Sep 17 00:00:00 2001 From: adela Date: Sun, 19 Apr 2026 22:52:51 +0200 Subject: [PATCH] docs: refresh supabase-vs-firebase for 2026 12-month refresh covering major 2025-2026 shifts: - Firebase Data Connect (managed PostgreSQL via Cloud SQL) as first-class database option - Supabase Branching GA, physical read replicas, background Edge Functions - Local dev + preview environments comparison (new section) - Self-hosting comparison (new section) - Updated AI/ML: Firebase AI Logic, Genkit, Firebase Studio vs Supabase pgvector, MCP, pg_mooncake - Updated pricing for both platforms - Added FAQ section (7 questions) - Cross-links to Neon, Convex, Supabase-to-AWS migration, DCM Co-Authored-By: Claude Opus 4.6 --- content/blog/supabase-vs-firebase.md | 307 +++++++++++++++++++-------- 1 file changed, 214 insertions(+), 93 deletions(-) diff --git a/content/blog/supabase-vs-firebase.md b/content/blog/supabase-vs-firebase.md index 68506994b..c3c0586ad 100644 --- a/content/blog/supabase-vs-firebase.md +++ b/content/blog/supabase-vs-firebase.md @@ -1,159 +1,280 @@ --- -title: 'Supabase vs. Firebase: a Complete Comparison in 2025' +title: 'Supabase vs. Firebase: a Complete Comparison in 2026' author: Adela -updated_at: 2025/04/19 18:00 +updated_at: 2026/04/19 18:00 feature_image: /content/blog/supabase-vs-firebase/banner.webp tags: Comparison -description: 'An extensive comparison between Supabase and Firebase in 2025' +description: 'Supabase vs. Firebase compared across database, auth, real-time, serverless functions, AI, local dev, self-hosting, and pricing — updated for 2026 with Firebase Data Connect, Supabase Branching, and the latest product shifts.' --- -This post is maintained by Bytebase, an open-source database DevSecOps tool which supports Supabase. We update the post every year. +This post is maintained by Bytebase, an open-source database DevSecOps tool which supports both Supabase and Firebase Data Connect. We update the post every year. -| Update History | Comment | -| -------------- | ---------------- | -| 2025/04/19 | Initial version. | +| Update History | Comment | +| -------------- | ----------------------------------------------------------------------------------------------- | +| 2025/04/19 | Initial version. | +| 2026/04/19 | Firebase Data Connect (PostgreSQL backend), Supabase Branching GA, AI tooling, updated pricing. | ## Introduction -Supabase and Firebase are two leading **Backend-as-a-Service (BaaS) platforms** that enable developers to build applications without handling backend infrastructure. While they serve similar purposes, they take fundamentally different approaches. +Supabase and Firebase are two leading **Backend-as-a-Service (BaaS) platforms** that let developers ship applications without managing backend infrastructure. They used to sit on opposite sides of the relational / NoSQL divide — that line has moved. -**Firebase** began in 2011 as a real-time NoSQL database and was acquired by Google in 2014. Since then, it has evolved into a comprehensive, fully-managed backend platform deeply integrated with the Google ecosystem. +**Firebase** began in 2011 as a real-time NoSQL database and was acquired by Google in 2014. In 2024 it launched **Firebase Data Connect**, a managed PostgreSQL backend with a GraphQL-like query layer — its first SQL offering, directly answering the comparison below. -**Supabase**, launched in 2020, emerged as an **open-source alternative** to Firebase. It’s built on **PostgreSQL**, offering a relational model with SQL support, and can be self-hosted for greater control and transparency. +**Supabase**, launched in 2020, emerged as an **open-source alternative** to Firebase, built on **PostgreSQL** with SQL support and self-hosting. Over 2025–2026 it shipped **Branching** (Git-based preview environments), physical read replicas, background Edge Functions, and MCP server integration for AI agents. -## Quick Comparison Table - -| Feature | Supabase | Firebase | -|---------|----------|----------| -| **Philosophy** | Open-source, standards-based | Proprietary, fully-managed | -| **Database Type** | PostgreSQL (Relational) | Firestore (NoSQL) & Realtime Database (NoSQL) | -| **Data Model** | Relational with tables, schemas, and SQL | Document-based with collections and documents | -| **Query Capabilities** | Full SQL support with joins, complex queries | Limited query options, no native joins | -| **Authentication** | Email/password, social, phone, MFA | Email/password, social, phone, MFA, anonymous | -| **Real-time** | PostgreSQL logical replication | Purpose-built real-time infrastructure | -| **Offline Support** | Basic, still evolving | Comprehensive, mature | -| **Functions** | Edge Functions (Deno) | Cloud Functions (Node.js, Python, Go, etc.) | -| **Storage** | S3-compatible with RLS | Google Cloud Storage with Security Rules | -| **AI/ML** | Vector database for embeddings, OpenAI/Hugging Face integrations, RAG support | Firebase Studio, Genkit, Gemini API integration, Vertex AI | -| **Pricing Model** | Predictable tiered pricing | Usage-based, pay-as-you-go | -| **Self-hosting** | Available | Not available | -| **Best For** | Data-intensive apps, SQL expertise, complex relationships | Mobile apps, real-time features, rapid prototyping | +The 2026 comparison is less "SQL vs. NoSQL" and more "open-source PostgreSQL platform vs. Google-ecosystem BaaS that now includes PostgreSQL." -## Core Philosophy and Approach - -**Supabase** embraces open-source technologies and standards, with PostgreSQL at its core. It provides direct SQL access and follows relational database principles, emphasizing data portability and avoiding vendor lock-in. +## Quick Comparison Table -**Firebase** takes a proprietary, fully-managed approach focused on developer experience and seamless integration. It abstracts away infrastructure complexities with NoSQL databases optimized for real-time synchronization and mobile use cases. +| Feature | Supabase | Firebase | +| ------------------------ | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | +| **Philosophy** | Open-source, standards-based, Postgres-first | Proprietary, fully-managed, Google ecosystem | +| **Database** | PostgreSQL (relational) | Firestore (NoSQL) + Realtime DB (NoSQL) + **Data Connect** (PostgreSQL via Cloud SQL) | +| **Query** | Full SQL, joins, CTEs, window functions | Firestore: document queries + vector search + aggregations; Data Connect: GraphQL over SQL | +| **Auth** | Email, social, phone, MFA, passkeys, anonymous | Email, social, phone, MFA, passkeys, anonymous | +| **Real-time** | Postgres logical replication + Phoenix Channels (Realtime v2) | Purpose-built Firestore/Realtime DB streams | +| **Offline support** | Client SDKs (basic) | Mature offline persistence in Firestore / Realtime DB | +| **Functions** | Edge Functions (Deno, TypeScript), background tasks, WebSocket | Cloud Functions (Node.js, Python, Go, Java, .NET), App Hosting (Next.js, Angular) | +| **Storage** | S3-compatible with RLS, Smart CDN | Google Cloud Storage with Security Rules | +| **AI / ML** | pgvector, pg_mooncake (Iceberg), MCP server, OpenAI/Hugging Face integrations | Firebase AI Logic, Genkit, Gemini API, Firestore vector search, Crashlytics AI | +| **Preview environments** | Supabase Branching (per-PR preview) | Hosting preview channels | +| **Local development** | `supabase start` (full local stack via Docker) | Firebase Emulator Suite (Firestore, Auth, Functions, etc.) | +| **Self-hosting** | Yes (open-source) | No | +| **Pricing model** | Predictable tiered ($0 / $25 / $599 / custom) | Usage-based pay-as-you-go (Blaze) on top of Spark free tier | +| **Best for** | SQL-first apps, open-source control, self-hosting, AI on Postgres | Mobile / web apps in Google ecosystem, real-time sync, rapid prototyping | + +## Core Philosophy + +**Supabase** embraces open-source and Postgres as the single source of truth. Auth, storage, edge functions, and real-time all read from and enforce policies in the same Postgres database. You can walk away with a `pg_dump` at any point. + +**Firebase** is Google-first and service-oriented — each capability (Firestore, Auth, Functions, Hosting, Data Connect) is a managed service with its own SDK. Data Connect narrowed the gap in 2024 by adding Postgres, but the operational model is still "Google manages it, you consume APIs." ## Database Capabilities -**Supabase** leverages PostgreSQL's powerful relational capabilities: +**Supabase** uses a single Postgres instance per project: -- Strong data consistency with full ACID compliance -- Support for complex queries, including joins and multi-step transactions -- Rich data types and advanced indexing for performance tuning -- Native support for stored procedures and triggers +- Full ACID, joins, CTEs, stored procedures, triggers +- PostgreSQL extensions (pgvector, PostGIS, pgmq, pg_cron, pg_mooncake for Iceberg) +- Physical read replicas (GA) +- Row Level Security as the primary authorization mechanism -**Firebase** offers two NoSQL database options: +**Firebase** now offers three database options: -- **Firestore:** A document-based database using collections and documents -- **Realtime Database:** A lightweight JSON tree structure optimized for real-time data synchronization +- **Firestore** — NoSQL document store with collections, strong offline support, and recent additions including vector search and aggregation queries (`count()`, `sum()`, `avg()`) +- **Realtime Database** — lightweight JSON tree, optimized for mobile real-time sync +- **Firebase Data Connect** — managed PostgreSQL (Cloud SQL under the hood) with a GraphQL-like query layer; addresses the historical "Firebase can't do joins" complaint -Supabase excels in complex data relationships and advanced querying, while Firebase prioritizes real-time synchronization and automatic scaling. +For most new projects, the choice inside Firebase is between Firestore (if you want the classic real-time mobile experience) and Data Connect (if you want relational). Supabase remains the simpler story if you want one Postgres database, no SDK-specific schemas, and full SQL access. + +For a deeper look at managed Postgres trade-offs, see [Neon vs. Supabase](/blog/neon-vs-supabase). ## Authentication and Security -Both platforms offer comprehensive authentication with email/password, social logins, and multi-factor authentication. +Both platforms cover the mainstream cases — email/password, OAuth social providers, phone, MFA, and passkeys (GA on both in 2025). **Supabase**: -- Built on **PostgreSQL Row Level Security (RLS)**. -- Access control is enforced through **SQL-based policies**, allowing fine-grained, table-level permissions. -- Offers flexibility and transparency, ideal for SQL-savvy teams. +- Uses **Postgres Row Level Security (RLS)** — access rules live in SQL and apply identically whether the client is a browser, a mobile app, or a backend service +- Service role key for trusted server-side code; anon key for public access +- Ideal for teams with SQL expertise that want one authorization model across the stack **Firebase**: -- Uses **Firebase Security Rules**, written in a **JavaScript-like syntax**. -- Rules are service-specific (e.g., Firestore, Storage), enabling dynamic access control based on user roles and request context. -- Tight integration with Google services makes setup straightforward, especially for front-end developers. +- Firestore / Realtime DB use **Firebase Security Rules** (JavaScript-like DSL) +- Data Connect uses **IAM + per-query authorization** defined in the GraphQL schema +- Cloud Functions can act as gatekeepers for write paths +- Ideal for front-end-heavy teams already in the Google ecosystem -Supabase provides **database-native** security controls ideal for complex permission schemes, while Firebase offers **service-specific** rules that are easier to implement for common scenarios. Supabase's SQL-based RLS gives more granular database control, whereas Firebase rules are more approachable for developers without SQL experience. +The philosophical difference: Supabase enforces auth inside the database engine; Firebase enforces it per service. Both work — the question is whether you want one policy language or several. -## Real-time and Offline Capabilities +## Real-time and Offline -**Firebase** offers battle-tested real-time features with: +**Firebase** remains the gold standard for mobile real-time: -- Automatic data synchronization across clients -- Built-in offline support with local persistence -- Automatic conflict resolution and smooth reconnection handling +- Firestore and Realtime Database sync automatically across clients +- Mature offline persistence — writes queue locally and replay on reconnect +- Automatic conflict resolution, retry, and exponential backoff -**Supabase Realtime** is powered by PostgreSQL logical replication and Phoenix Channels: +**Supabase Realtime (v2)** leverages Postgres logical replication + Phoenix Channels: -- Enables database change subscriptions, including INSERT, UPDATE, DELETE events -- Supports presence tracking for multiplayer or collaborative use cases +- Subscribe to INSERT / UPDATE / DELETE events at the table or row level +- Presence tracking for multiplayer apps +- Broadcast channel for ephemeral messages +- Offline support in client SDKs is improving but still less mature than Firestore -Firebase leads in offline resilience and real-time maturity, while Supabase offers powerful server-driven change tracking with a relational foundation, best suited for applications needing strong data consistency. +If offline-first mobile is the main use case, Firebase still wins. For collaborative web apps and server-driven change streams, Supabase is a strong fit. ## Serverless Functions -**Supabase Edge Functions** are built on the **Deno runtime**, supporting **TypeScript and JavaScript**, and are designed to run at the edge for low-latency performance. These functions have direct access to the Supabase PostgreSQL database, making them ideal for lightweight APIs and custom logic tightly coupled with the database. +**Supabase Edge Functions** (Deno / TypeScript): + +- Run at the edge for low latency +- Direct access to the Supabase Postgres database via the service role key +- **Background tasks** (long-running jobs) and **WebSocket** support added in 2025 +- Lightweight and database-aware; best for API endpoints and custom auth hooks + +**Firebase Cloud Functions & App Hosting**: -**Firebase Cloud Functions** support multiple runtimes, including **Node.js, Python, and Go**, and can be triggered by a wide range of events — such as HTTP requests, Firestore updates, authentication events, and Pub/Sub messages. They are deeply integrated with Google Cloud Platform for scalability and flexibility. +- **Cloud Functions** — Node.js, Python, Go, Java, .NET runtimes triggered by HTTP, Firestore, Auth events, Pub/Sub, and more +- **App Hosting** (GA) — first-class hosting for Next.js and Angular apps with server-side rendering, replacing the legacy Firebase Hosting for full-stack JS apps +- Tight GCP integration; good for teams that need broad runtime support -Supabase Edge Functions are **lightweight, TypeScript-native, and database-aware**, while Firebase Cloud Functions provide **broad language support, rich trigger options, and tight integration** with the wider Google Cloud ecosystem. +Supabase Edge Functions are lean and TypeScript-native. Firebase gives you more runtime options and a hosted Next.js/Angular platform. ## AI and Machine Learning -**Firebase** offers a comprehensive, cloud-based AI development ecosystem: +The AI story moved significantly in 2025–2026. -- **Firebase Studio**: Cloud development environment for AI apps with Gemini integration. -- **Genkit**: Open-source framework for building AI features with generative models. -- **Vertex AI Integration**: Direct access to Google's Gemini models for text, image, video, and audio. -- **AI-assisted Development**: Gemini assistance for coding and app development. +**Firebase**: + +- **Firebase AI Logic** — SDK for calling Gemini / Imagen directly from client apps without a custom backend +- **Genkit** (GA) — open-source framework for building generative AI features in TypeScript, Go +- **Firebase Studio** — cloud IDE with built-in Gemini assistance (replaces Project IDX) +- **Vertex AI** integration for production ML workloads +- **Firestore vector search** — native similarity search for embeddings +- **Crashlytics AI Insights** — Gemini-generated crash analysis -**Supabase** takes a database-centric approach to AI: +**Supabase**: -- **Vector Database (pgvector)**: PostgreSQL extension for vector similarity search. -- **AI Toolkit**: Tools for storing, indexing, and querying vector embeddings. -- **Semantic Search**: Built-in capabilities for meaning-based search. -- **AI Integrations**: Support for OpenAI, Hugging Face, LangChain, and other providers. +- **pgvector** — the Postgres extension for vector similarity search, maturing with HNSW indexes +- **MCP server** — official Model Context Protocol integration so AI agents (Claude, Cursor, etc.) can query Supabase safely +- **pg_mooncake** — Iceberg tables inside Postgres for analytics / RAG datasets at scale +- **AI assistant** in the Supabase dashboard — generate SQL and RLS policies from natural language +- Integrations with OpenAI, Hugging Face, LangChain, LlamaIndex -**Firebase** excels with its fully integrated AI development environment and seamless access to Google's advanced models. **Supabase** shines by offering flexible, database-native AI capabilities built on PostgreSQL, ideal for developers who want tight control over their AI data infrastructure. +**Firebase** wins on end-to-end developer convenience and first-party Gemini access. **Supabase** wins if you want your AI data layer to be Postgres — one database for transactional, semantic, and analytical workloads. -## Pricing Models +## Local Development and Preview Environments -| | **Supabase** (Predictable Tiered Pricing) | **Firebase** (Usage-Based, à la Carte Pricing) | -|-----------------------|----------------------------------------------------------------------|------------------------------------------------------------------------| -| **Free Tier** | Generous limits | Daily/monthly quotas | -| **Paid Plans** | Pro plan ($25/month), plus Team and Enterprise options | Blaze plan (pay-per-operation), integrated with Google Cloud billing | -| **Cost Structure** | Fixed, predictable pricing | Variable, pay-as-you-go per usage | -| **Scalability** | Better for growing teams needing cost predictability | May be cheaper for small apps, but expensive as usage scales | -| **Analogy** | Fixed-price buffet: predictable and straightforward | À la carte menu: flexible but potentially unpredictable costs | +This is where the 2025–2026 refresh changed the most. + +**Supabase**: + +- `supabase start` spins up the entire stack (Postgres + Auth + Storage + Edge Functions + Studio UI) locally via Docker +- **Supabase Branching** — every Git branch / PR can create an isolated database + API preview, matching Vercel-style preview environments +- Seeds and migrations travel with the repo; PRs can run schema changes against the branch before merging + +**Firebase**: + +- **Firebase Emulator Suite** — local emulators for Firestore, Realtime DB, Auth, Functions, Storage, Hosting +- **Hosting preview channels** — short-lived URLs per PR for the hosted frontend +- No native database preview-per-PR for Firestore; Data Connect's PostgreSQL backend can be point-in-time cloned via Cloud SQL + +For teams that care about "open this PR, get a fresh database to test against," Supabase Branching is a clear advantage. For emulating the full Firebase service surface locally, the Emulator Suite is mature. + +## Self-Hosting + +**Supabase** is open-source (Apache 2.0 for most components) and self-hostable. The reference self-hosted stack runs on Docker Compose; production deployments typically use Kubernetes or managed Postgres underneath. Critically, self-hosting means **no data leaves your infrastructure** — relevant for compliance (SOC 2, HIPAA, GDPR data residency). + +**Firebase** is closed-source and Google-hosted. There's no self-hosting path. If you need on-prem or air-gapped, Firebase isn't an option. + +If you ever need to migrate off Supabase, see [How to Migrate from Supabase to AWS](/blog/how-to-migrate-from-supabase-to-aws). + +## Pricing + +| | **Supabase** | **Firebase** | +| ------------------ | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- | +| **Free tier** | Free plan — 500MB database, 1GB storage, 50K MAUs, 2 active projects | Spark plan — free daily / monthly quotas per service (no billing attached) | +| **Paid entry** | Pro — $25/month/project (8GB DB, 100GB bandwidth, daily backups, PITR) | Blaze — pay-as-you-go per operation (reads, writes, function invocations) | +| **Team / mid** | Team — $599/month/org (SOC 2, SSO, audit log, priority support) | Blaze with higher usage; no flat mid-tier | +| **Enterprise** | Custom (on-prem / BYO cloud, custom SLAs) | Custom (via Google Cloud sales) | +| **Cost shape** | Predictable flat per-project | Scales linearly with usage; cheap small, can surprise at scale | +| **Analogy** | Fixed-price buffet | À la carte menu | + +Small apps are often cheaper on Firebase's Spark + Blaze combination. At scale, Supabase's flat pricing becomes easier to forecast — Firestore read/write charges compound quickly with real-time listeners and fan-out workloads. ## Performance and Reliability -**Firebase** +**Firebase**: + +- Google's global infrastructure; multi-region replication available on most services +- Automatic horizontal scaling with minimal configuration +- Optimized for global mobile real-time sync + +**Supabase**: + +- Hosted on AWS in multiple regions +- **Physical read replicas** (GA) for read scaling +- Postgres connection pooling via Supavisor +- Requires some tuning for high-concurrency workloads; pays off with Postgres-native query performance + +Firebase is "set and forget" at global scale. Supabase gives you more knobs — connection pooling, indexes, query plans, replica routing — which is an advantage if you have the SQL expertise and a disadvantage if you don't. + +## Database Change Management + +Schema evolution is where BaaS platforms historically under-invest. + +- **Supabase** migrations live in SQL files in the Git repo and are applied via the Supabase CLI (`supabase db push`). Branching makes it natural to review schema changes per PR +- **Firebase Data Connect** schemas live in `.gql` files alongside the app and are deployed via the Firebase CLI +- **Firestore** has no schema; you enforce shape in Security Rules or a Data Connect layer + +For teams that want review, approval, rollback, and audit on database changes across environments — regardless of platform — [Bytebase](https://www.bytebase.com/) adds a review-and-approval workflow on top of Supabase (and any other Postgres host). -- Built on **Google's global infrastructure** -- **Automatic scaling** with minimal configuration -- **Multi-region replication** ensures high availability and low latency -- Optimized for **real-time data synchronization** and global distribution -- Ideal for apps needing instant updates and seamless scalability +## When to Choose Supabase -**Supabase** +- You want **Postgres as the system of record** with full SQL access +- You need **self-hosting** or data residency control +- You want **per-PR database previews** via Branching +- Your AI stack benefits from pgvector + Postgres in one place +- You prefer flat, predictable pricing over usage-based billing -- Hosted on **AWS** with support for multiple regions -- Offers **read replicas** for scaling read-heavy workloads -- Requires **manual performance tuning** for high-traffic or complex queries -- Capable of strong performance, especially for **relational workloads** -- **More control and flexibility**, but with added configuration overhead +## When to Choose Firebase -Firebase offers "set-and-forget" performance at global scale, while Supabase provides more control for database tuning at the cost of manual optimization. Firebase handles traffic spikes automatically, whereas Supabase requires planning for high-load scenarios but can achieve better PostgreSQL-specific performance. +- You're building a **mobile-first app** with real-time sync and offline needs +- You're already in the **Google ecosystem** (Gemini, GCP, Google Analytics) +- You want **rapid prototyping** with minimal infra decisions +- You need **multiple runtimes** for serverless (Python, Go, Java, .NET) +- You want **Firebase AI Logic** for client-side Gemini calls without custom backend ## Conclusion -Choose Supabase for SQL-powered apps needing PostgreSQL flexibility, open-source control, or AI vector support. Opt for Firebase if you prioritize real-time mobile apps, rapid prototyping, and Google's ecosystem. Supabase offers deeper database control; Firebase delivers effortless scaling and real-time sync. \ No newline at end of file +In 2026 the comparison is narrower than it used to be. Firebase Data Connect gave Firebase a Postgres story; Supabase shipped Branching, read replicas, and MCP. Pick Supabase if you want one open Postgres to power everything, including AI. Pick Firebase if you want Google-grade managed services and a mobile-first real-time experience. + +## FAQ + +### Is Firebase Data Connect a real alternative to Supabase? + +Yes, for the Postgres-and-GraphQL use case. Firebase Data Connect runs on Cloud SQL for PostgreSQL and exposes a GraphQL-like query layer. Where it differs: you don't get direct SQL access in the same way, schema modeling is done in `.gql` files, and self-hosting isn't an option. If you want open-source Postgres with SQL, Supabase is still the better fit; if you want Google-managed Postgres inside the Firebase console, Data Connect is viable. + +### Can I use Supabase and Firebase together? + +Possible but uncommon. Teams sometimes use Firebase Auth + Cloud Messaging for mobile identity/push while keeping data in Supabase Postgres — the SDKs don't fight each other. More often, teams pick one platform and commit. + +### Which is cheaper? + +For small apps with low traffic, Firebase's Spark (free) + Blaze (pay-per-op) is often cheaper because you pay nothing until you grow. Supabase's $25 Pro entry is a fixed cost. At scale (millions of real-time listeners, heavy fan-out), Supabase's flat pricing usually wins because Firestore per-operation costs compound. Run projected usage through each pricing calculator before deciding. + +### Does Supabase support mobile offline like Firebase? + +Partially. Supabase client SDKs have basic offline handling but Firebase's Firestore offline persistence is the mature standard. For offline-first mobile apps, Firestore or Realtime Database still has the edge. + +### Can I self-host Firebase? + +No. Firebase is closed-source and Google-hosted. If self-hosting is a hard requirement (air-gapped, on-prem, strict data residency), Firebase is off the table — consider Supabase or a different stack entirely. + +### How do I handle schema migrations on Supabase and Firebase? + +- **Supabase**: SQL migration files in Git, applied with `supabase db push`. Branching creates per-PR preview databases to test migrations before merge +- **Firebase Data Connect**: `.gql` schema files, deployed with `firebase deploy --only dataconnect` +- **Firestore**: no schema, but you can enforce structure in Security Rules or add a Data Connect layer + +For cross-environment review, approval, and audit on any Postgres (including Supabase), see [What is Database Change Management](/blog/what-is-database-change-management). + +### What about Neon or PlanetScale as alternatives? + +Neon is a serverless Postgres platform with branching similar to Supabase's but without the BaaS layer (no built-in auth / storage / edge functions). PlanetScale is MySQL-based, serverless, with strong branching but no Postgres. See [Neon vs. Supabase](/blog/neon-vs-supabase) for a full comparison. + +--- + +Related reading: + +- [Neon vs. Supabase](/blog/neon-vs-supabase) +- [Convex vs. Supabase](/blog/convex-vs-supabase) +- [Supabase vs. AWS Database Pricing](/blog/supabase-vs-aws-database-pricing) +- [How to Migrate from Supabase to AWS](/blog/how-to-migrate-from-supabase-to-aws) +- [Supabase vs. MongoDB](/blog/supabase-vs-mongodb) +- [What is Database Change Management](/blog/what-is-database-change-management)