I just watched a founder spend three weeks evaluating databases for a product that doesn’t have paying customers yet. Three weeks. He built comparison spreadsheets. He ran benchmarks. He consulted two different CTOs over coffee. He posted on Reddit and got 47 conflicting opinions.

He ended up choosing Postgres. Which is what he should have chosen on day one and saved himself three weeks.

Look, I get it. Database choice feels important because it is important, eventually. When you’ve got millions of rows and complex query patterns and real-time requirements, your database architecture matters enormously. But you don’t have any of that right now. You’ve got a Notion doc, a Figma prototype, and a dream.

The Only Question That Matters

Here’s the decision framework I give every early-stage founder who asks me about databases:

Do you know exactly what your data model looks like and it’s relational? Use Postgres.

Is your data model uncertain and might change significantly? Use Postgres.

Are you building something weird and specific that needs a specialised database? Probably still use Postgres, but fine, let’s talk.

I’m being slightly reductive, but only slightly. Supabase has made Postgres so easy to set up that there’s almost no reason not to default to it. You get a hosted database, authentication, real-time subscriptions, and an API layer in about five minutes. For free, until you have enough traffic to actually need a paid plan.

But What About MongoDB?

MongoDB is fine. It’s not evil. If you’ve used it before and you’re comfortable with it, go ahead. But the “we chose Mongo because our data is unstructured” argument usually translates to “we haven’t thought about our data model yet.” That’s not a database problem. That’s a product problem.

The document model is legitimately better for some use cases. If you’re building something where each record has a genuinely different shape, like a CMS where every content type has different fields, MongoDB makes sense. But for most startups building SaaS products, user profiles, transactions, subscriptions, and so on, relational data is relational data, and Postgres handles it beautifully.

The Trendy Options

Every year there’s a new database that tech Twitter falls in love with. Last year it was Turso (SQLite at the edge). The year before that it was PlanetScale. Before that, FaunaDB, CockroachDB, and whatever else had a good Product Hunt launch.

Some of these are genuinely innovative. Turso’s approach of running SQLite at the edge is clever and solves a real problem for certain architectures. But here’s the thing: solving a real problem at scale is not the same as solving your problem at your scale.

When you have 12 users, edge latency doesn’t matter. When you have 50 users, multi-region replication doesn’t matter. When you have 200 users, sharding doesn’t matter.

You know what matters when you have 200 users? Building the features they’re asking for. Shipping fast. Iterating on feedback. Not debugging an obscure issue with a database you chose because someone impressive recommended it on a podcast.

What Actually Goes Wrong

In my experience, early-stage database problems almost never stem from choosing the wrong database. They stem from:

Not having indexes. Your queries are slow because you didn’t add an index on the column you’re filtering by, not because you chose the wrong database engine.

N+1 queries. You’re making 500 database calls to render a single page because your ORM is doing something silly. Fix your queries, don’t switch databases.

No migrations strategy. You’re manually modifying the production database because you never set up a proper migration tool. This will bite you regardless of which database you’re using.

Storing files in the database. Don’t put images and PDFs in your database. Use S3 or Cloudflare R2 and store the URL. This applies to every database ever made.

When Database Choice Actually Matters

There are legitimate scenarios where your choice matters from day one:

Real-time collaborative apps (like Figma-style products) might need something like Liveblocks or a CRDT-based approach from the start.

Search-heavy applications probably need Elasticsearch or Meilisearch alongside your primary database.

Time-series data (IoT sensors, financial tick data) is genuinely better served by purpose-built databases like TimescaleDB or InfluxDB.

Graph-heavy data (social networks, recommendation engines) might justify Neo4j or similar.

But notice these are all specific, identifiable use cases. If your use case doesn’t obviously fall into one of these buckets, you don’t need a specialised database. You need Postgres and a good night’s sleep.

My Actual Advice

1. Use Postgres via Supabase or Railway. Set it up in ten minutes.
2. Use a proper ORM or query builder. Prisma, Drizzle, or Kysely if you’re in the TypeScript world.
3. Set up database migrations from day one. It takes twenty minutes and saves you weeks of pain later.
4. Write the simplest queries that work. Optimise when (if) you hit performance problems.
5. Spend the three weeks you saved actually building your product.

The database you don’t overthink is the database that lets you ship.

Jack Reeves is a startup founder and technology advisor based in Australia.