Supabase, Firebase, or Neon? You’re Probably Asking the Wrong Question
A few months ago, someone asked me:
“If you were starting a new project today, what would you choose? Supabase? Firebase? Neon? Convex?”
I told them:
“I still don’t know what you’re building.”
They were a little disappointed.
They probably expected a decisive answer: the hottest technology of the month, plus a short explanation of why everything else was already irrelevant.
But most of the time, the question itself is the problem.
Because most developers don’t choose a database.
They choose the technology they watched on YouTube this week, then invent reasons why it was an engineering decision.
I know.
I’ve done it too.
The mistake that cost me more time than I’m willing to admit
Somewhere around 2015, everyone was talking about Firebase.
It was new.
It was realtime.
It was fast.
It was cool.
And most importantly, it felt like the future.
So I got on the train too.
Not because I had spent time analyzing the system’s needs.
Not because I compared alternatives.
Not because I built a proof of concept.
Just because everyone was talking about it.
And at first?
It was brilliant.
Development was fast. Everything felt simple. Every demo worked. Every new feature landed quickly. I was convinced I had made a great decision.
Then the product started becoming an actual product.
Suddenly I needed to connect information from different places. Cross-reference data. Answer questions I hadn’t thought of on day one.
And suddenly I was doing one read.
Then another.
Then another.
Then one more to stitch it all together in code.
Not because Firebase was a bad product.
Quite the opposite. Firebase was an excellent product.
The problem was that I had chosen technology for a different problem, then tried to convince myself that I was the problem.
I spent more time working around the limits of my choice than building the product itself.
It was one of the first times in my career that I understood something important:
The coolest technology in the room isn’t necessarily the technology you need.
Since then, whenever someone asks me how to choose a database, I come back to three simple questions.
1. What does your data actually look like?
Not which database has the most GitHub stars.
Not what the last podcast you heard recommended.
Not what Claude suggested.
What does your data actually look like?
If you work with users, orders, products, invoices, permissions, relationships between entities, and data that needs joining together, you’re probably in Postgres territory.
If most of your data looks like independent objects or JSON documents, something like Firebase or Convex may feel much more natural.
The rule is simple:
Don’t choose a database based on hype.
Choose a database based on the shape of your data.
At the end of the day, the data always wins over the architecture you drew on the whiteboard.
2. How much code do you not want to write?
This is the question almost nobody asks.
Everyone compares databases. Very few people compare everything around them.
Auth.
Storage.
Permissions.
Realtime.
Backups.
Monitoring.
Functions.
The reason people like Supabase is not only Postgres.
It solves a lot of problems you’d otherwise have to solve yourself.
The same is true for other platforms.
So the question isn’t:
“What’s the best database?”
The question is:
“What will get me to my first user fastest?”
That’s usually the question that actually matters.
3. How easy will it be to leave?
I know.
Nobody likes thinking about divorce on their wedding day.
You should anyway.
Some platforms let you move on relatively easily. Others become an inseparable part of your app.
That’s not necessarily bad. You just need to understand the price.
Because when you choose a database, you’re not only choosing where to store data.
You’re choosing a relationship.
It helps to know in advance how messy a breakup could be.
So what would I choose?
If I were starting a new project tomorrow, with no special requirements and no unusual constraints?
Probably Postgres.
Not because it’s the newest.
Not because it’s the fastest.
Not because it’s the sexiest.
Because it’s boring.
And after more than 20 years in the industry, I’ve learned that boring is usually an excellent sign.
Boring means a lot of people have already made the mistakes for you.
Boring means your AI will know exactly how to solve most bugs.
Boring means someone will still know how to maintain what you built ten years from now.
The bottom line
The older I get as a developer, the more I realize that fewer and fewer decisions require the perfect solution.
It’s more important to make a reasonable decision and move.
It’s less important to find the ultimate choice.
A database is just one example.
Because in the end, most startups don’t fail because of a database.
They fail because nobody used the product.
So choose something reasonable.
Start building.
And if, in two years, you discover you chose wrong?
That’ll probably be one of the better problems you have.