Database Choice 2026 — Postgres, MongoDB, SQLite, Supabase

For new web apps in 2026, the default database is PostgreSQL. Specifically, hosted Postgres via Supabase, Neon, or PlanetScale. Most other choices are either wrong or specialized.

This guide explains why, what the alternatives are, and when they actually win.

---

The Short Answer

Use Case	Best Choice
New web app (default)	PostgreSQL (via Supabase, Neon)
Local development / single-user	SQLite
Embedded analytics	DuckDB
Document store with denormalized data	MongoDB
Massive scale write-heavy	PostgreSQL with sharding, or Cassandra
Real-time apps	Supabase or Firebase
Edge-distributed	Cloudflare D1 or Turso
Vector search for AI	Postgres + pgvector
Time series	TimescaleDB (Postgres) or ClickHouse
Simplest possible	SQLite

PostgreSQL wins almost every category in 2026 except niche specializations. The "what database should I use?" question often has the same answer.

---

Why PostgreSQL Won

PostgreSQL became the default web app database because:

1. Mature and feature-rich. 30+ years of development. Handles almost anything.

2. Standards-compliant SQL. Skills transfer to other SQL databases.

3. Extensions ecosystem. PostGIS (geography), pgvector (AI), TimescaleDB (time series), etc.

4. Performance. Excellent for most workloads up to billions of rows.

5. ACID compliant. Real transactions, real consistency guarantees.

6. JSON support. JSONB columns get document database flexibility within relational integrity.

7. Open source + commercial support. No vendor lock-in.

8. Available everywhere. Every cloud, every framework.

The result: PostgreSQL replaced MySQL as the new default. MongoDB never was the default outside specific contexts.

---

PostgreSQL Hosting Options 2026

Supabase

Free tier: Generous (500MB database, 50K monthly users) Paid: $25-599/month

Bundled features:

• Postgres database
• Auth (built-in)
• Realtime subscriptions
• Storage
• Edge functions
• Admin UI

Best for: New projects wanting backend-as-a-service with Postgres.

Neon

Free tier: 0.5GB, autoscale, branches Paid: $19+/month

Distinguishing features:

• Database branching (like Git)
• Serverless (scales to zero)
• Read replicas
• Native Postgres compatibility

Best for: Modern serverless workflows. Each PR gets its own database branch.

PlanetScale

Note: Originally MySQL, but added Postgres support in 2024.

Best for: Teams that want branching workflow with strong tooling.

Self-Hosted (DIY)

Run PostgreSQL on your own server (Hetzner, DigitalOcean, AWS).

Cost: $5-50/month for small databases.

Trade-off: You handle backups, monitoring, upgrades. Worth it for cost-sensitive or specific compliance requirements.

AWS RDS, Google Cloud SQL, Azure Database

Cost: $30-3000+/month.

Trade-off: Reliable, full-featured, but expensive vs Supabase/Neon. Worth it for established AWS shops.

---

SQLite: Underrated Champion

For many apps, SQLite is the right answer:

Strengths:

• Embedded in your application (no separate database server)
• Single file (mydb.sqlite) — easy backup, migration
• Fastest local performance
• Zero configuration
• Excellent SQL support

When SQLite wins:

• Local-first apps (no central database needed)
• Single-server apps with moderate scale (handles millions of rows)
• Mobile apps
• Desktop apps
• Edge databases (Cloudflare D1, Turso are SQLite-based)

Real numbers: SQLite handles ~100K writes/sec on modern hardware. Most apps never need more.

# Use SQLite — it's just this simple
import sqlite3
conn = sqlite3.connect('mydata.db')
cursor = conn.cursor()
cursor.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
cursor.execute("INSERT INTO users (name) VALUES (?)", ("Alice",))
conn.commit()

Tools like Turso make SQLite serverless and globally replicated — making it viable for many cloud apps too.

---

When MongoDB Actually Makes Sense

MongoDB is often the wrong choice. But it has legitimate uses:

Genuinely good for:

1. Deeply nested document structures where joins would be painful
2. Highly variable schemas changing rapidly
3. Content management with arbitrary fields per document
4. Catalog data with very different attributes per item

Often misused for:

1. Relational data (use Postgres)
2. Apps with transactions across documents (MongoDB ACID came late, still limited)
3. Reporting (analytical queries on MongoDB are painful)
4. "We might not know our schema" — actually you do, you're just deferring decisions

The 2010s NoSQL hype overstated MongoDB's benefits. Most apps that picked MongoDB then would do better on Postgres now.

PostgreSQL's JSONB columns give you 80% of MongoDB's flexibility while keeping relational integrity:

-- Postgres with JSON
CREATE TABLE products (
 id SERIAL PRIMARY KEY,
 name TEXT,
 attributes JSONB -- Can store arbitrary fields
);

INSERT INTO products (name, attributes) VALUES
 ('Phone', '{"color": "blue", "storage": "256GB"}'),
 ('Laptop', '{"ram": "32GB", "cpu": "M3"}');

-- Query JSON fields
SELECT * FROM products WHERE attributes->>'color' = 'blue';

-- Index JSON fields
CREATE INDEX idx_color ON products ((attributes->>'color'));

Best of both worlds.

---

Specialized Databases

Time Series

If you have lots of timestamped data (metrics, sensor data, financial):

• TimescaleDB — PostgreSQL extension. Best Postgres-compatible option.
• InfluxDB — Purpose-built for time series
• ClickHouse — Analytical, excellent for time series at scale
• QuestDB — Specialized, fast

For most apps with some time-series tables: stick with Postgres until you hit specific scaling problems.

Vector Search (AI Workloads)

For embedding-based search (RAG, semantic search):

• pgvector — PostgreSQL extension. Run alongside your relational data.
• Pinecone — Managed vector database
• Weaviate — Open source
• Chroma — Lightweight, embedded
• Qdrant — Rust-based, fast

In 2026: most teams use pgvector for moderate scale. Dedicated vector DBs when scaling beyond millions of vectors.

See: RAG Systems Explained.

Graph Databases

For deeply interconnected data (social networks, knowledge graphs):

• Neo4j — Most popular
• TigerGraph — Scale focus
• DGraph — Open source, GraphQL native
• PostgreSQL with AGE extension — Graph in Postgres

For most apps: model relationships in Postgres tables with proper indexes. Move to graph DB only when graph traversal is your central use case.

Search Engines (Full-Text)

• PostgreSQL's built-in full-text search — fine for most apps
• Elasticsearch / OpenSearch — Industry standard for serious search
• Meilisearch — Modern alternative, easier to operate
• Typesense — Similar to Meilisearch
• Algolia — Hosted SaaS, premium UX

If your full-text needs are basic: Postgres handles it. For Google-like search experience: use a dedicated engine.

Real-Time Databases

For apps with lots of live subscriptions:

• Supabase (Postgres + realtime)
• Firebase Realtime Database / Firestore
• PartyKit (Cloudflare-based)
• Liveblocks (for collaborative apps specifically)

Build real-time on top of Postgres usually. Specialized tools when collaborative features are central.

---

ORM Choice

Almost equally important as database choice:

Prisma (TypeScript)

Most popular ORM in modern TypeScript world.

// Schema
model User {
 id String @id @default(cuid())
 email String @unique
 posts Post[]
}

// Queries — fully typed
const user = await prisma.user.findUnique({
 where: { email: 'alice@example.com' },
 include: { posts: { take: 5 } }
});
// user is fully typed!

Strengths: Excellent TypeScript integration, mature, great migrations. Weaknesses: Can be slow at scale, some query patterns awkward.

Drizzle (TypeScript)

Newer, lighter, more SQL-like.

import { drizzle } from 'drizzle-orm/postgres-js';
import { eq } from 'drizzle-orm';

const users = await db.select().from(usersTable).where(eq(usersTable.email, 'alice@example.com'));

Strengths: Closer to SQL, smaller bundle, fast. Weaknesses: Less mature than Prisma, smaller ecosystem.

SQLAlchemy (Python)

The standard for Python. Mature, capable.

Django ORM

Built into Django. Excellent for Django-based apps.

Raw SQL

Always an option. With prepared statements, no ORM is fine for many apps:

const users = await sql`SELECT * FROM users WHERE email = ${email}`;

Libraries like postgres (npm) make this clean and safe.

For new TypeScript projects in 2026: Prisma or Drizzle. For existing Python projects: SQLAlchemy. For minimal projects: raw SQL is fine.

---

Schema Migration Tools

Every database needs migrations:

• Prisma Migrate — Excellent, declarative
• Drizzle Kit — Modern, type-safe
• Flyway — Java ecosystem, language-agnostic
• Alembic — SQLAlchemy migrations
• Atlas — Modern, declarative, cross-database
• dbmate — Simple language-agnostic

For Prisma users: Prisma Migrate. For Drizzle: Drizzle Kit. For everyone else: pick based on language.

---

Scaling Considerations

Read Scale

PostgreSQL scales reads well:

• Up to ~100K queries/sec on big servers
• Add read replicas for more
• Connection pooling (PgBouncer, Pgcat) essential

Write Scale

PostgreSQL writes:

• ~10-50K writes/sec on single instance
• Beyond that: partitioning, sharding, or specialized DBs

Most apps never hit these limits. Premature scaling is more common than actual scaling problems.

Cost at Scale

Database Size	Supabase	Neon	AWS RDS	Self-Hosted
1 GB	Free	Free	$30/mo	$5/mo VPS
10 GB	$25/mo	$19/mo	$50/mo	$10/mo
100 GB	$99/mo	$69/mo	$200/mo	$30/mo
1 TB	$599/mo	$299/mo	$1000/mo	$100/mo

Self-hosting saves money at scale but adds ops burden. Most teams find managed worth the cost up to a point.

---

Anti-Patterns to Avoid

1. Choosing MongoDB for relational data. Don't.

2. Storing media files in the database. Use blob storage (S3, R2), reference in DB.

3. No indexes on filtered/joined columns. Quickly causes slow queries.

4. SELECT * in production. Fetch only what you need.

5. N+1 queries from ORM. Use eager loading (include, with, etc.).

6. Reading directly from production DB for analytics. Use a separate analytics DB.

7. Not using transactions for related writes. Causes inconsistent state.

8. Single huge tables without partitioning. Eventually slow.

---

Real Project Recommendations

Solo Developer / Side Project

• Database: SQLite (or Supabase free tier)
• ORM: Prisma or raw SQL
• Cost: $0

Startup MVP

• Database: Supabase or Neon (Postgres)
• ORM: Prisma or Drizzle
• Cost: $0-25/month

Growing SaaS

• Database: Supabase or self-hosted Postgres
• Add: read replicas, monitoring, backups
• ORM: Prisma + connection pooling
• Cost: $50-500/month

Enterprise / High Scale

• Database: AWS RDS or self-hosted Postgres cluster
• Add: read replicas, partitioning, monitoring stack
• Maybe: ClickHouse for analytics, Redis for cache
• ORM: Mix of ORM + raw SQL for hot paths
• Cost: $1K-50K+/month

---

FAQ

Q: Should I use MySQL or PostgreSQL? A: PostgreSQL for new projects. MySQL fine for existing apps. Most new development chose Postgres after 2020.

Q: When is Firebase right? A: Real-time consumer apps, small teams, willing to pay for managed convenience. Firestore can get expensive at scale.

Q: NoSQL ever the right choice? A: Yes, for specific cases (very nested data, varying schemas, massive write scale). Often the wrong choice for "we might not know our schema."

Q: What about distributed SQL (CockroachDB, Yugabyte)? A: Excellent for true multi-region apps needing strong consistency at scale. Usually overkill for most apps.

Q: Self-host or managed? A: Managed (Supabase, Neon, AWS RDS) until cost exceeds engineering value. Self-hosting at scale saves money but requires ops expertise.

---

Related Articles

• GraphQL vs REST vs tRPC 2026
• Next.js vs React 2026
• Best Web Development Tools 2026
• Web Security Essentials 2026

---

Bottom Line

PostgreSQL via Supabase/Neon is the right default for new web apps in 2026. SQLite for local-first apps. MongoDB only for specific document use cases.

The "what database?" question used to be complicated. In 2026, the answer is usually "Postgres" — and the more interesting question is which managed service.

Pick boring technology. Most database problems are caused by exotic choices, not Postgres-related issues.

Last verified: May 2026