Firebase’s fast start risks migration

Firebase’s real constraint is that it collapses app logic into a database shaped workflow, which is great for getting a prototype live and much less great for building a broad, long lived product. Teams get auth, storage, sync, and client SDKs fast, but they also inherit document database tradeoffs, per operation pricing, and a data model that can make richer querying and backend customization feel cramped as the product grows.

• The cost issue is real, but it is not only about big bills. Firestore charges on reads, writes, deletes, storage, bandwidth, and even index entry reads for some queries, so product decisions like polling, feeds, and filtering can directly change infrastructure cost in ways that feel less predictable than running a relational database.
  4 google 5 google
• The data model matters just as much. Firebase’s core database products are document or key value oriented. That works well for chat, presence, and simple app state, but it can become awkward when the product needs joins, complex reporting, or many related tables. That is why Postgres based products like Supabase have gained traction as a more durable backend starting point.
  1 sacra 2 sacra 6 sacra 7 supabase
• Next.js and Vercel solve a different problem. They mostly improve the workflow for building and shipping the app surface, like previews, deploys, and server rendering, while Firebase tries to replace backend infrastructure itself. In practice, teams are more likely to outgrow a backend abstraction than a frontend deployment workflow.
  1 sacra 3 sacra 8 google 9 google

The direction of travel is toward products that keep Firebase’s fast start but remove the feeling of an eventual rewrite. That is why open source, Postgres based backends and more flexible full stack frameworks keep gaining share. The winning stack is likely to be the one that lets a two person team move fast on day one and still looks familiar when the company has fifty engineers.