Firestore saved me from schema hell
If you’re building for a client who keeps shifting the goalpost, here’s some honest advice:
Avoid SQL until the spec is stable.
You’ll save yourself from endless migrations, broken data, and wasted hours.
💥 Why SQL is a bad idea in chaotic projects
- Every schema change = manual migration
- Every migration = rollback risk
- Every miscommunication = broken relations or corrupted data
It’s like building a skyscraper with a blueprint drawn in crayon.
✅ Why Firestore (NoSQL) saved me
No migrations
Just start writing data. Add new fields whenever. No tables to alter. No DB admin.Nested data, no problem
Need a user profile with 5 settings and a subcollection of comments? Firestore handles that like it’s native.Speed over structure
Perfect for MVPs. When the client changes their mind (again), you don’t have to rewrite half your DB logic.Schema-less = stress-less
You don’t get yelled at for not “planning ahead.” You just ship.
⚖️ But if you have to use SQL…
Some teams/projects require relational DBs. Here are tools that make the pain tolerable:
- Prisma Type-safe, declarative schema, powerful migration engine
- Knex.js + Objection.js Mature and battle-tested in Node environments
- Atlas by Ariga Clean migration workflows, good for CI/CD
-
Supabase 🔥 Firebase-like developer experience on top of PostgreSQL
- Instant APIs
- Auth + storage included
- Web UI for managing schema/migrations
- Great for teams that need SQL but want NoSQL-level velocity
Why Supabase is different
Even though it’s SQL under the hood, Supabase makes schema changes easier to manage. You can:
- View and edit tables in the dashboard
- Auto-generate APIs
- Roll back or push migrations with Git workflows
It's a great compromise if your project is too relational for Firestore but still in flux.
TL;DR
If the client says “we’re still figuring it out,” avoid SQL unless you enjoy stress.
- ✅ Use Firestore when things are unstable or MVP
- ✅ Use Supabase if you need SQL but want NoSQL flexibility
- ✅ Use proper migration tools (Prisma, Knex, Atlas) if you're stuck with raw SQL
Choose tools that match the reality of the project, not what sounds good on paper.
Top comments (2)
I think this is a problem that is going to haunt you for the rest of the time you work with that client.
Basing a post on this premise is a bad start in my mind.
While I agree SQL is not the silver bullet for all applications, the choice should be based on the technical requirements.
SQL is easy-peasy 😊 . If you use MVC correctly, this is an none issue. I've worked with NoSQL and SQL for many years, It's much easier to express complex queries in SQL than NoSQL.
I store some data in MongoDB. Building a complex pipeline is such a pain; even a simple thing like GROUP BY becomes an ugly mess, whereas SQL is readable and understandable at a glance because it's just English.