Tool Directory / Databases
Choose the database your app will not outgrow
The database is the hardest layer to change later. Frameworks get rewritten in a quarter; a schema and five years of production data do not move that easily. Which is why the correct answer is usually the boring one, and why this page starts there.
Reviewed August 2026. Back to the tool directory.
What this layer decides
Three questions settle it. Do you need more than one writer at once? Do you need the data close to the user, or is one region fine? And how much operational work are you willing to own - backups, failover, connection pooling, version upgrades?
A useful thing happened in 2026: the feature gaps mostly closed. Postgres, MySQL, MongoDB, and SQLite all do vector search now. Postgres does JSON documents well enough that "we need a document store" is rarely true. That leaves operational fit as the real differentiator, not the feature matrix.
Relational databases
Where the overwhelming majority of applications should live, including most of the ones that think they need something else.
PostgreSQL
18.x - the default answer
Postgres 18 continued a decade of quietly absorbing everything else: JSONB documents, full-text search, geospatial via PostGIS, vectors via pgvector, and queues via SKIP LOCKED. Managed options are everywhere and cheap, from Neon and Supabase to plain RDS. Unless you have a specific reason not to, this is the answer, and "we might need X later" is not a reason. postgresql.org
SQLite
Embedded - wildly underrated
A single file, zero network hops, and query latency measured in microseconds because there is no connection to make. In WAL mode it handles a surprising amount of concurrent read traffic with one writer, which describes most web applications honestly measured. Add Litestream to stream continuous backups to object storage and the durability objection mostly evaporates. sqlite.org
MySQL
8.4 LTS - fine, not exciting
Still enormous in the wild and perfectly capable, with 8.4 as the long-term line and a separate innovation track that moved to calendar versioning in 2026. Choose it when your team already runs it, when PlanetScale-style branching is the workflow you want, or for legacy PHP applications. For greenfield work Postgres has the better extension story. mysql.com
Distributed SQLite and edge data
Turso
SQLite, replicated
Built on libSQL, a fork of SQLite that adds a server mode and replication, with embedded replicas that keep a local copy in sync from a remote primary. That combination gives you local-file read speed with a durable central write path. The company has since started a ground-up Rust rewrite and a Postgres-compatible effort, so watch which product line you are adopting. turso.tech
Litestream
Backups for the file-based crowd
A sidecar process that continuously replicates a SQLite WAL to S3-compatible storage and restores from it on boot. It is the piece that makes "just use SQLite on one server" a defensible production decision rather than a dare. No sharding, no multi-writer, no magic - just point-in-time recovery for a file. litestream.io
Document stores, caches, and vectors
MongoDB
Version 8 is a real improvement and Atlas is a genuinely good managed service with integrated vector search. But the case for starting here has narrowed: Postgres JSONB covers schemaless data, and most teams eventually want joins and constraints they gave up.
Redis
Still the reference in-memory store for caching, rate limiting, sessions, and queues. Redis 8 added AGPLv3 back alongside the source-available licenses, which defused most of the 2024 fallout. Check the license terms before you embed it in a product you resell.
Valkey
The Linux Foundation fork of Redis, Apache 2.0 licensed and backed by AWS, Google, and Oracle. Version 8 added multi-threaded I/O and lower memory use. Drop-in compatible for typical workloads, and usually cheaper on managed cloud.
pgvector
Vector similarity search as a Postgres extension. For anything under a few million embeddings this beats running a separate vector database, because your vectors sit next to the rows they describe and stay in one backup.
Dedicated vector databases such as Pinecone, Qdrant, and Chroma still earn their place at very large embedding counts or when you need specialized index types. Below that scale, adding a second datastore buys you a second thing to keep in sync, back up, and pay for.
Our pick
Managed Postgres 18, with SQLite as the small-app default
Run managed Postgres. It handles relational data, JSON documents, full-text search, geospatial queries, background job queues, and vector embeddings in one system you only have to back up once. Every hosting platform offers it, every ORM supports it first, and hiring someone who knows it is trivial.
The exception worth taking seriously: if the app runs on a single server and has one writer, SQLite plus Litestream is faster, cheaper, and simpler than any network database, and it is a genuinely defensible production choice. Reach for Turso when you need the same model replicated across regions.
Keep going
Postgres vs SQLite
When a file beats a server, and when it absolutely does not.
Read the verdictMySQL vs Postgres
The oldest argument in web development, settled for 2026.
Read the verdictORMs and query builders
How your code talks to whichever database you just picked.
Browse the layerSQL cheatsheet
Joins, window functions, and indexes in one reference page.
Grab the cheatsheetBuilding something specific? The SaaS stack and AI app stack guides both commit to a database choice and explain the reasoning behind it.