The Database Decision Tree I Use in 2026
Postgres until proven otherwise, but here's what proves otherwise.
Founders ask me which database to pick more than any other architectural question. I've codified the decision into a tree I actually use on calls. Here it is.
Every founder I work with asks the database question in the first hour of the first call. I've answered it enough times that I keep a decision tree open during scoping. This is that tree.
Step 1: Are you sure you don't want Postgres?
If your answer is "I don't know", the answer is Postgres. Specifically, Postgres 16 on AWS RDS or Supabase. Move on. Read no further.
The reason: Postgres handles relational data, JSON, full-text search, geospatial queries, time-series with TimescaleDB, vector search with pgvector, and queues with SKIP LOCKED. The vast majority of "we need a different database" decisions are made by engineers who haven't read the Postgres docs.
I have a longer post on this.
Step 2: Do you have a real reason to deviate?
The reasons I accept:
- You're storing more than 5TB of hot data on a single shard. Postgres can do it, but operational overhead climbs. Consider Aurora, CockroachDB, or partitioning strategies.
- You need sub-millisecond key-value reads at millions of QPS. Use Redis or DynamoDB.
- You're building a search product as the core feature. Use OpenSearch or Elastic. Postgres FTS is fine for a search box, not for a search product.
- You have hard regulatory geo-residency for many regions. A globally distributed database (Spanner, CockroachDB) earns its keep here.
- Your data is genuinely a graph and queries are 4+ hops deep. Use Neo4j. Most "graph" data is actually relational with a self-join.
If none of those apply, go back to step 1.
Step 3: Pick by failure mode, not by feature list
Vendor sites compare features. They don't compare what happens when things go wrong. That's actually all that matters.
- Postgres: vacuum can stall under heavy write load, replication lag is the common silent failure. Mitigation is mature, the community is huge.
- MongoDB: schemaless feels great until year 2, when you find seven shapes of the same document and no migration plan.
- DynamoDB: query patterns are baked into your data model. Changing access patterns post-launch is an actual rewrite.
- CockroachDB: serializable isolation is the default and your queries will be slower than Postgres for the same workload. You're paying for global consistency. Make sure you need it.
- ClickHouse: spectacular for analytics, miserable for transactional updates. Use it as a sink, not a source of truth.
Step 4: Operations beat architecture
The best database for your team is the one you can operate at 3am on a Sunday. If your team has run Postgres for years, do not introduce DynamoDB because it's "serverless". You will pay for that decision in incidents.
I've seen three startups in the last year switch from Postgres to a distributed database, hit operational pain they couldn't debug, and switch back. The migration both ways cost six engineering months each.
Step 5: The 90% answer
For 90% of products I see at the audit stage:
- Primary store: Postgres, managed, with point-in-time recovery and a read replica.
- Cache: Redis, managed.
- Search: Postgres full-text, until you have a real search product.
- Analytics: ClickHouse or BigQuery, fed from Postgres CDC.
- Vectors: pgvector, until you exceed 50 million vectors.
That stack will take you to Series B without architectural pain. It's also the stack I run for production fintech.
The sharper insight
The database is the slowest-to-change part of your architecture. Frameworks change every 18 months, languages every five years, databases every ten or never. Pick one you'd be happy operating in 2030. The "exciting" choice is usually the wrong one for the job that matters: still being there when you need it.
If you'd like me to walk through your specific situation, that's exactly what the architecture audit is for. Two weeks, fixed price, you get a written recommendation.