For a SaaS built to scale, the right default is PostgreSQL. It covers roughly 90% of what a web or mobile product needs: transactional data, relationships between entities, search, JSON, lightweight queues, and even part of the vector workload for AI. The real question is almost never "relational or NoSQL" — it’s "do I have a specific reason NOT to use Postgres". Most of the time, you don’t.
PostgreSQL by default: why it works 9 times out of 10
A SaaS handles structured, interconnected data: users belonging to organizations, subscriptions tied to invoices, projects tied to tasks. That is exactly what relational databases are built for. Postgres layers super-powers on top of that foundation so you don’t have to stack extra tools: JSONB columns for semi-structured data, built-in full-text search, the pgvector extension for AI embeddings, and constraints that guarantee your data stays consistent.
- ACID transactions: your payments and critical data stay consistent, even after a crash.
- One system to operate, back up and monitor instead of three — lower cost, fewer outages.
- Mature ecosystem: Prisma, migrations, replication, managed hosting everywhere (Cloud Run, Neon, Supabase, RDS).
- JSONB when you need flexibility, without giving up relational guarantees for the rest.
Relational vs NoSQL: when to leave Postgres
NoSQL (MongoDB, DynamoDB, Firestore) isn’t "more modern" — it answers different constraints. It only pays off when your use case genuinely fits: massive write-heavy volume, a truly unpredictable schema, or a need for extreme geographic distribution. For a typical B2B SaaS in its launch and growth phase, those constraints don’t exist yet — and adopting NoSQL too early makes you pay in complexity for something you’ll never use.
Picking NoSQL because "it scales" when you have 200 users is optimizing a problem you don’t have — at the expense of the ones you already do.
Indexes, migrations, scaling: three reflexes to have from V1
A well-chosen database isn’t enough: three habits decide whether your SaaS holds up at 10,000 users. First, indexes — a query that scans a whole table is fast at 100 rows and catastrophic at 1 million. Index the columns you filter and join on often, and measure with EXPLAIN. Next, migrations: every schema change must be versioned and replayable (Prisma Migrate), never applied by hand in production. Finally, scaling: go vertical first (more CPU/RAM), add read replicas, and only think about sharding very late — most SaaS never get there.
- Indexes: target the columns in WHERE, JOIN and ORDER BY clauses; a bad index costs writes, a missing one kills reads.
- Migrations: versioned, tested, reversible — the database evolves with the product without downtime.
- Scaling: vertical first, then read replicas; Postgres handles millions of rows long before sharding ever comes up.
The right call for a V1
Choosing PostgreSQL from day one, modeling cleanly, laying down the right indexes and versioning migrations: that’s what saves you a rewrite at month 12. It’s exactly the foundation we set up in our V1s shipped in 7 days for €15,000 — Next.js, NestJS, Prisma and Postgres — a database that carries you from your first customer to scale, with no hidden technical debt.