Supabase reduces vendor lock-in with Postgres

Firebase’s database choice matters because it changes the shape of the whole app, not just where data is stored. Cloud Firestore is a document database, so developers model data as collections, documents, and nested fields instead of tables, joins, and SQL. That makes Firebase fast to start with for chat, feeds, and mobile sync, but it also means business logic, queries, and permissions get built around Firebase specific patterns, which raises switching costs later compared with Supabase’s Postgres based approach.

• In practice, lock in comes from the data model and tooling together. Firestore stores JSON like documents in collections, uses its own querying model, and commonly pairs that with Firebase Auth, Storage, and Security Rules, so moving off Firebase often means rewriting schema design, access rules, and app code at the same time.
  1 google 2 google 4 sacra
• Supabase positions against that by keeping the BaaS experience but building on PostgreSQL. Developers still get auth, storage, realtime APIs, and hosted infrastructure, but the underlying database is relational and widely portable, which makes self hosting, direct SQL access, and later migration materially easier.
  3 sacra 4 sacra 5 sacra
• Appwrite sits closer to Supabase than Firebase on the lock in question. Its docs say the product uses SQL under the hood today, even if the API feels NoSQL like, which means the competitive split in BaaS is increasingly between proprietary document stacks and open, self hostable SQL stacks.
  5 sacra 6 appwrite

Going forward, the winning BaaS products will keep Firebase’s speed while reducing the pain of outgrowing it. That is why Postgres based backends like Supabase have become the natural landing spot as apps move from prototype to production, and why open database foundations are becoming a core product differentiator, not just an infrastructure detail.