Database Choices in 2025: The Practical Guide

Database conversations get religious. They shouldn’t.

Here’s the practical guide to choosing a database in 2025.

The Default Answer

For 90% of startups: Postgres.

If you’re reading this trying to decide, just pick Postgres and move on. You probably don’t have special requirements that justify anything else.

When Postgres Is the Answer

Standard Web Applications

User data, content, transactions, reporting. Postgres handles all of it.

JSONB columns let you store unstructured data when needed. You get relational reliability with document flexibility.

Analytics and Reporting

Postgres handles analytical queries well enough for startup scale.

Need more? Add TimescaleDB for time-series. Or connect to a data warehouse later.

Vector Search / AI Applications

pgvector extension adds vector similarity search. Good enough for most RAG applications.

You don’t need Pinecone until you do. Start with Postgres.

Full-text search in Postgres is underrated. Works for most applications.

Add Elasticsearch when you need advanced search. Not before.

When to Consider Alternatives

MongoDB: Truly Unstructured Data

Use when: Your data genuinely doesn’t have consistent structure. Document schemas vary significantly.

Examples: CMS platforms with flexible content types, logging systems, event stores.

Don’t use for: Data that could be relational. Most data is actually relational.

MongoDB is good at what it does. It’s just not what most startups need.

MySQL: Legacy or WordPress

Use when: You’re building on WordPress, or integrating with systems that require MySQL.

Don’t use for: New projects without MySQL requirements. Postgres is better in almost every way.

MySQL is fine. Postgres is better.

Redis: Caching and Sessions

Use when: You need fast caching, session storage, or simple message queues.

Use alongside: A primary database. Redis isn’t your source of truth.

Essential tool. Wrong choice as primary database.

DynamoDB: AWS All-In

Use when: You’re deep in AWS and need infinite scale with minimal ops.

Watch out for: Expensive at scale, vendor lock-in, requires different thinking.

Good for specific use cases. Not a general-purpose choice.

The New Databases

PlanetScale (Serverless MySQL)

MySQL-compatible, scales automatically, branching for development.

Good for: Teams who want MySQL with modern developer experience.

We tried it. Good product. Still prefer Postgres ecosystem.

Supabase (Postgres-as-a-Service)

Postgres with auth, storage, and realtime features built in.

Good for: Rapid prototyping, teams who want batteries included.

We use it for some projects. Great developer experience.

Neon (Serverless Postgres)

Scale-to-zero Postgres with branching.

Good for: Development environments, projects with variable load.

Promising for cost optimization on variable-traffic applications.

CockroachDB (Distributed SQL)

Postgres-compatible, globally distributed, survives region failures.

Good for: If you actually need multi-region writes. Most startups don’t.

Overkill for 99% of applications.

The Managed vs. Self-Hosted Decision

Use Managed

  • You’re a startup (your time is worth more than hosting cost)
  • You don’t have database expertise
  • You want to sleep at night

Options: AWS RDS, Google Cloud SQL, Supabase, Railway, Render

Self-Host If

  • Extreme cost sensitivity (10x data size makes managed expensive)
  • Compliance requirements
  • You have the expertise

For most startups: Managed. Always managed.

Common Mistakes

Multiple Databases Too Early

“We’ll use Postgres for users and MongoDB for products.”

Why? Complexity. Transactions across systems. Data consistency headaches.

Use one database. Add others only when forced.

Premature Optimization

“We need to scale to millions of users.”

You have 100 users. Any database handles that. Pick one and build.

Scaling problems are good problems. Solve them when you have them.

NoSQL Because It’s Cool

SQL was invented in 1970. Still works. Relational databases are battle-tested.

NoSQL is right for some problems. But “relational databases are old” isn’t a good reason.

Ignoring Backups

Every managed database has backups. Verify they work.

Test restoring from backup. Once per quarter minimum.

The database you can’t restore is worthless.

The Migration Question

“Can I switch databases later?”

Technically yes. Practically painful.

Some abstraction layers (Prisma, SQLAlchemy) make it easier. Complete portability is a myth.

Choose carefully upfront. Migrations are expensive.

Our Setup

Primary: Postgres on Supabase Cache: Redis on AWS Elasticache Search: Postgres full-text (considering Elasticsearch when needed) Analytics: Postgres + warehouse connection for heavy analysis

Simple. Maintainable. Boring in the best way.

The Decision Framework

  1. Do you have special requirements? (Multi-region, massive scale, specific compliance) No → Postgres Yes → Research specifically for that requirement

  2. Do you need document flexibility? No → Postgres Yes → Postgres with JSONB (or MongoDB if truly unstructured)

  3. Do you need graph relationships? No → Postgres Yes → Consider Neo4j (but Postgres can often work)

  4. Do you need time-series optimization? No → Postgres Yes → TimescaleDB (Postgres extension)

Notice a pattern? Postgres handles most requirements.

The Summary

Start with Postgres. Add specialized databases only when Postgres genuinely can’t solve the problem.

You’ll probably never hit that point. And that’s fine.

Boring technology choices let you focus on building your product. That’s the goal.