Databases (Tools)

In one line: Postgres for the data. Redis for the cache. SQLite at the edge. Specialized databases (search, vector, graph) only when Postgres can't.

→ Going deeper: Advanced Databases covers indexes and the query planner (EXPLAIN), transaction isolation, the N+1 problem, and safe schema migrations.

In plain English

The database is where your app's data actually lives. The 2026 default is PostgreSQL — open-source, mature, has extensions for almost every specialized need (vectors, time-series, geospatial, full-text search). Add Redis when you need fast caching. Reach for anything else only when you have a specific problem Postgres can't solve.

PostgreSQL — the default

In 2026, PostgreSQL is the default relational database for almost every new project.

Why:

• Open-source, no licensing concerns.
• Feature-rich (JSON, full-text search, GIS, time-series, vectors).
• Excellent extension ecosystem.
• Mature managed offerings.
• Strong ACID guarantees.

Notable extensions:

• pgvector — Vector similarity search (for AI/RAG).
• PostGIS — Geographic data.
• TimescaleDB — Time-series optimization.
• pg_search — Full-text search.
• pg-boss — Background jobs.

Managed Postgres providers

Provider	Notes
Supabase	Postgres + Auth + Storage + Realtime + Edge Functions. All-in-one backend.
Neon	Serverless Postgres with branching (each PR can have its own DB branch).
Railway	Simple managed DB alongside app hosting.
PlanetScale (Postgres)	Branching, schema changes without locks.
AWS RDS	Mature, full control, more operational burden.
Google Cloud SQL / Azure Database	Same idea for other clouds.

SQLite

A single-file database. Used to be considered "embedded only," but in 2026 it's production-viable via:

• Cloudflare D1 — SQLite at the edge.
• Turso — Distributed SQLite with replication.
• Litestream — Streaming backup for SQLite to S3.

When SQLite makes sense: Edge-first apps, single-region apps with moderate write volume, apps that benefit from running queries with zero network latency.

MySQL

Still common in legacy systems. PlanetScale popularized serverless MySQL (now deprecated in favor of Postgres).

For new projects, Postgres is almost always preferred.

MongoDB

Document database. Popular in 2015–2020.

Where it still fits: Apps with genuinely schemaless data, content management systems, certain analytics workloads.

Where Postgres beats it: Almost everything else. Postgres's JSON columns + relational data are usually better.

DynamoDB (AWS)

Serverless NoSQL store. Scales infinitely, predictable performance.

When to use: AWS-native apps with simple access patterns; massive scale where Postgres limits are real. Trade-off: Hard to query in flexible ways; "you must know your access patterns up front."

Redis / Valkey

In-memory key-value store. Used for:

• Caching
• Session storage
• Rate limiting
• Job queues (with BullMQ)
• Leaderboards (sorted sets)
• Pub/sub messaging

Managed: Upstash (serverless), Redis Cloud, AWS ElastiCache.

Valkey is the open-source fork after Redis's license change. Many cloud providers are migrating to it.

Search engines

Engine	Notes
Typesense	Modern, fast, easy to operate. Popular for new projects.
Meilisearch	Similar to Typesense; great DX.
Algolia	Hosted, very fast, expensive at scale.
Elasticsearch	Powerful, complex, dominant historically.

Often, Postgres full-text search is enough — one less service to operate.

Vector databases

For storing embeddings (high-dimensional vectors that represent meaning).

• pgvector — Postgres extension; the popular 2026 choice.
• Pinecone — Managed, easy to start.
• Qdrant — Open-source, fast.
• Weaviate — Open-source, feature-rich.
• Turbopuffer — Newer, cost-optimized.

Recommendation: Use pgvector unless you have specific needs that justify a separate service.

Analytics databases

For OLAP (analytical queries on large datasets):

• ClickHouse — Columnar, blazing fast.
• DuckDB — In-process analytics; great for local data work.
• Snowflake / BigQuery — Cloud data warehouses.

Graph databases

For data with complex relationships (social networks, recommendations):

• Neo4j — Most popular, Cypher query language.
• Amazon Neptune — AWS managed.

Often Postgres + recursive CTEs is enough for "I just need some graph queries" use cases.

Highlight: the 2026 default data stack

For 95% of new projects, this is the right starting point:

That's it. One DB to back up. One mental model. One ops burden. Add specialized databases only when Postgres genuinely can't handle the job — which, in 2026, is rare.

Common mistakes

Where people commonly trip up

• Reaching for MongoDB because "my data is unstructured." It almost never is. Users, orders, posts, and comments are relational — and Postgres has a jsonb column for the genuinely schemaless bits. You get joins, transactions, and constraints for free; in Mongo you'd hand-roll them.
• Adding a dedicated vector database before you've shipped one AI feature. pgvector inside the Postgres you already run is the right starting point. Pinecone/Qdrant/Weaviate add a service to operate, a second source of truth, and another bill. Move to one only when pgvector hits a real wall.
• Treating Redis as durable storage. Redis is in-memory; a restart or eviction can drop your data. Use it for caches, sessions, rate limits, queues — never as the system of record. If you need persistence, that's Postgres's job.
• Connecting to Postgres from a serverless function without a connection pooler. Each cold start opens a fresh connection; under load you hit the connection limit and the whole DB falls over. Use a pooler (PgBouncer, Supabase's pooler, Neon's connection pooling) for serverless workloads.
• Skipping indexes until the query is slow. By then, "slow" means a customer-facing outage. Index foreign keys and any column you filter or sort by — that's table stakes, not optimization.
• Picking DynamoDB because it "scales infinitely." It does, but only along the access patterns you designed for. Add a new query shape later and you're rebuilding tables. If you can't enumerate every query up front, you want Postgres.

Page checkpoint

Checkpoint Quiz

Did databases stick?

Required

What's next

→ Continue to ORMs & Database Tools — the layer that translates between your code and SQL.