Ask ten founders which database to use for a new SaaS product and you will get eleven answers, most of them delivered with far more confidence than the evidence supports. Choosing a database for your SaaS startup gets treated online like a philosophical debate, when in reality it is one of the more boring decisions you will make. I have shipped four SaaS products now, and the database engine has never once been the reason one of them struggled.
What actually causes pain later is not the choice between Postgres, MySQL or something more exotic. It is how you structure your data for multiple customers from day one, and whether you took migrations seriously before you had six months of production data riding on getting it right. That is the part nobody argues about online, and it is the part that actually matters.
The database argument online is mostly noise
Spend an hour reading engineering forums about database choice and you would think the wrong pick sinks companies regularly. It does not. I cannot think of a single SaaS business I know personally that failed because of its database engine. I know several that struggled because nobody thought about tenancy, backups or query patterns until it was expensive to fix.
The people arguing loudest about NoSQL versus relational databases are usually operating at a scale you are nowhere near yet, or they are engineers who enjoy the argument more than they enjoy shipping product. Neither group is thinking about your actual problem, which is getting a working product in front of paying customers as fast as possible.
Start with Postgres unless you have a specific reason not to
For almost every SaaS product I would start with Postgres and I would not spend more than an afternoon deciding that. It is relational, it is mature, it handles the vast majority of query patterns a business application will ever throw at it, and the tooling around it is excellent. Hosted options from every major cloud provider mean you are not managing the operational overhead yourself either.
The honest reason most SaaS products should default to Postgres is that your actual product data, users, subscriptions, records, permissions, is relational whether you like it or not. Things belong to other things. Customers have invoices. Invoices have line items. Fighting that structure with a document database because it looks more modern on a job advert is a decision you will regret the day you need a report that joins four tables together.
The multi tenancy decision matters more than the engine
The decision that actually shapes your future far more than the database engine is how you isolate customer data. Shared schema with a tenant column, schema per tenant, or database per tenant. This is the conversation I wish more founders had before writing a single line of code, because changing it later is genuinely painful.
With CampSuite I went with a shared schema and a tenant identifier on every table, and I have written in more detail about what that architecture decision actually cost me over the years. It was the right call for the scale I was operating at, but it came with trade offs around noisy neighbours and data isolation that a database per tenant model would have avoided. There is no universally correct answer here, only the one that matches how many customers you expect and how much isolation they will actually demand.
When you actually need something else
There are genuine cases where something other than a relational database is the right call, and it is worth being honest about them rather than pretending Postgres solves everything. Full text search at real scale benefits from a dedicated search engine sitting alongside your relational store rather than trying to force it through SQL. High volume event data, logging, or time series metrics are usually better served by something built for that write pattern.
Caching is not a database replacement, it is an addition. Redis sitting in front of Postgres to take the load off expensive queries is a completely different decision to replacing Postgres with something else entirely. Conflating the two is one of the more common mistakes I see early stage teams make when they read a blog post about a company operating at a hundred times their scale and decide they need the same architecture on day one.
Mistakes I made getting this wrong
I have made my share of mistakes here. Early on with one product I under invested in migrations discipline, treating schema changes as something to bolt on rather than something to design properly from the start. By the time the product had real customers and real data, every schema change became a genuinely stressful event rather than a routine one.
I have also seen the opposite mistake up close, advising a business that had built an elaborate sharded architecture for a product with barely a hundred customers. The engineering time spent on infrastructure nobody needed yet would have been far better spent talking to those hundred customers and working out what to build next. If you are still validating whether people want your product, and that stage of the journey is exactly what I cover in The 28 Day Startup, your database architecture should be the least interesting decision you make that week.
The framework I actually use now
These days my approach is straightforward. Default to Postgres. Decide your tenancy model deliberately rather than by accident, based on how many customers you expect and how much data isolation they will genuinely ask for. Take migrations seriously from the first commit, not the first incident. Add specialised tools like search engines or caching layers when a specific, measured problem demands it, not because a conference talk made it sound inevitable.
None of that is exciting advice, and that is rather the point. The database decision should be one of the quicker calls you make when building a SaaS product, so you can spend your actual energy on the things that decide whether the business works at all, whether anyone wants what you are building, and whether you can get it in front of them. I have written more generally about how I think about the wider tech stack decision if you want the fuller picture beyond just the database.
