The short answer

If you are building an indie SaaS and you want a default that will not punish you later, start on managed Postgres. It is the most adopted open-source relational database among professional developers right now, and every major cloud platform has a first-class managed Postgres tier with a free or near-free starting price. Managed MySQL is a fine second choice, especially if your stack already speaks MySQL or you are leaning on a CMS or analytics workload. SQLite is not a toy, but it is also not a general SaaS database. Use it where it actually shines: single-tenant, embedded, or read-heavy local-first products.

That is the headline. The rest of this guide walks through the cost, the migration ceiling, the backup story, and the workload patterns so you can pick with eyes open.

Why this choice matters more than it looks

The database is one of the few pieces of an indie SaaS where a wrong early choice quietly compounds. Switching engines later means rewriting ORMs, retuning indexes, redoing backups, and re-explaining everything to your hosting bill. A solo founder does not have a spare week for that.

Three trends are worth keeping in mind before you decide:

  • Postgres has momentum. Stack Overflow’s developer surveys have repeatedly shown Postgres as the most admired and most desired database among professional developers for several years running, with MySQL overtaking it only among those still learning.
  • Cloud platforms are Postgres-first. Every major application platform offering a hosted database now offers Postgres. That means better free tiers, better connection pooling, and better serverless options for solo builders.
  • SQLite quietly grew up. It now supports JSON, generated columns, and full-text search. That changes what counts as a realistic workload for it.

Cost at low traffic, honestly

You will hear that managed Postgres costs more than managed MySQL. In practice, on the entry tier most providers offer, they cost roughly the same. The real cost differences come from a few specific knobs:

  • Connection-based pricing is the trap. Postgres uses a process per connection, MySQL is more forgiving with thread reuse. If your serverless functions each open a fresh connection, you will pay for it on Postgres before you pay for it on MySQL. A small connection pooler fixes this and is essentially mandatory for serverless Postgres.
  • Free tiers exist, but they vary. Most cloud vendors offer a small managed Postgres instance for free or a few dollars a month, usually with a storage cap and a row or connection limit. Read the fine print on automatic sleeps, row caps, and storage caps before you build on top of it.
  • Storage growth is the slow leak. Both managed Postgres and managed MySQL bill on gigabytes. As your audit logs, events, and analytics tables grow, your bill grows. Plan a 90-day retention policy before launch, not after your first invoice shock.
  • SQLite can be free for a long time. A single SQLite file on disk has no per-row or per-connection cost. The hidden cost is operational: backups, replication, and concurrency ceilings.

For an indie SaaS that is pre-launch or in early beta, the cheapest realistic answer is usually a managed Postgres free tier plus a connection pooler. The bill may literally be zero until you have real users.

The migration ceiling

This is the question that should actually drive your choice: how far can this database take me before I have to migrate?

Managed Postgres has the highest ceiling. It handles JSON when you want it, full-text search without a separate service, row-level security when you finally add multi-tenant isolation, generated columns, rich window functions, and a deep extensions ecosystem. If your SaaS suddenly needs geospatial queries, time-series, or vector search, Postgres has an extension for all of those. Migration off Postgres is rarely necessary.

Managed MySQL has a slightly lower ceiling for advanced SQL, but still a very high one for typical SaaS workloads. It is mature, well understood, and excellent for read-heavy patterns and simple OLTP. The main gaps versus Postgres are window function range units, row-level security out of the box, and the extensions ecosystem. For most SaaS CRUD, you will not feel those gaps.

SQLite has the lowest ceiling, and it is honest about it. SQLite is single-writer by design, which means write-heavy concurrent workloads will hit a wall. Replicas for read scaling exist but are not turnkey the way they are on Postgres or MySQL. SQLite’s ceiling is the limit of a single machine’s disk and a single writer’s throughput. For many products, that ceiling is plenty. For a multi-tenant SaaS with many concurrent writers, it is not.

Backup ergonomics

Backups are the part founders forget until they need them. The three options compare very differently here.

  • Managed Postgres and managed MySQL both ship with point-in-time recovery on most managed tiers, automated daily snapshots, and one-click restore to a new instance. This is the part of the managed tax you are actually paying for, and it is worth it. You do not need to write a backup script.
  • SQLite requires you to bring your own backup story. The naive approach, copying the file, is risky because SQLite is always mid-write. The safer patterns are the online backup API or a tool that handles hot snapshots. If you go SQLite, treat backup as a real project from day one, not an afterthought.

If you are a solo founder and you would rather not think about backups at all, managed Postgres or managed MySQL are the obvious choices.

Where each database actually pays off

Pick managed Postgres when:

  • You are building a multi-tenant SaaS and expect to add row-level security or per-tenant data isolation later.
  • You want JSON columns, full-text search, or geospatial queries without bolting on a second service.
  • You anticipate needing extensions for analytics, vectors, or time-series.
  • You want the largest pool of managed options, free tiers, and serverless tiers to choose from.

Pick managed MySQL when:

  • Your stack is already MySQL-flavored (WordPress, many CMSs, Magento, legacy code).
  • You are doing heavy read traffic with simple joins and want a forgiving, predictable database.
  • You want to join tables across databases, which MySQL allows natively and Postgres does not without the foreign data wrapper extension.
  • You have operational expertise in MySQL specifically and no time to learn a new dialect.

Pick SQLite when:

  • You are building a single-user, single-tenant, or local-first product where each customer has their own database file.
  • You are shipping an embedded product, a desktop app, or a CLI tool that needs a real database without a server.
  • You have a read-heavy workload with bursty or rare writes.
  • You explicitly want zero infrastructure and are comfortable owning backups, migrations, and replication yourself.

A practical decision flow

If you are still unsure, walk through this:

  1. Are you building multi-tenant SaaS with concurrent writes? Yes tilts toward managed Postgres. No keeps all three open.
  2. Will you need JSON queries, full-text search, or row-level security within the first year? Yes tilts toward managed Postgres. No keeps managed MySQL competitive.
  3. Is your stack already married to MySQL? Yes tilts toward managed MySQL. No keeps Postgres as the default.
  4. Are you shipping a single-user or per-customer file product? Yes tilts toward SQLite. No rules SQLite out for a SaaS backend.
  5. Do you want to never think about backups again? Yes tilts toward managed. No lets SQLite back in.

If you answered “yes” to one and “no” to the rest, you have your answer. If you are somewhere in the middle, managed Postgres is the safest default.

Concrete next steps

  • If you chose managed Postgres: pick a managed provider with a generous free tier, add a connection pooler in front of it from day one, and enable automated backups and point-in-time recovery before you write your first migration.
  • If you chose managed MySQL: same playbook. Verify the free tier’s storage and connection limits, and make sure automated backups are on by default.
  • If you chose SQLite: set up the online backup API or a wrapper tool that handles hot snapshots, write a restore drill, and document your migration path to Postgres for the day your product outgrows a single writer.

FAQ

Is SQLite safe for production? For the workloads it was designed for, yes. For a multi-tenant SaaS with many concurrent writers, no. Treat SQLite as a specialist tool, not a general-purpose SaaS database.

Can I start on SQLite and migrate to Postgres later? You can, but it costs engineering time you would rather spend on the product. If there is a real chance you will outgrow SQLite within a year, start on managed Postgres now and skip the rewrite.

Do I really need a connection pooler for Postgres? If you are using serverless functions or any pattern that opens many short-lived connections, yes. It is one of the most common gotchas for indie founders moving to managed Postgres.

Is MySQL simpler than Postgres? Historically, MySQL was considered easier to start with. Today, for most SaaS workloads, both are well documented and both ship with mature managed options. Pick based on your stack and your feature needs, not on perceived simplicity.

Sources