About / Editorial notes

Useful guidance earns its confidence.

Databases.how helps developers and small teams make database decisions they can explain, test, and operate.

How the selector works

The selector uses explicit rules, not a live benchmark or an AI-generated verdict. Its starting point comes from the main workload. Cloud preference, existing engine compatibility, scale, operating preference, budget priority, and—in relevant cases—regional writers or cache use refine the candidate and its notes. The directory covers database engines, managed services, and analytical platforms as distinct product entries; it is curated rather than exhaustive.

A modest local transactional workload with a low-spend priority can start with SQLite. Concurrent networked writers favor a client/server database.
Transactional writes in multiple regions with strict read expectations raise a distributed SQL candidate. The alternative is a simpler architecture with one write region.
Single-node analytics favors DuckDB. Shared managed analytics raises BigQuery; operating an analytical service yourself raises ClickHouse.
Primary key-value records and rebuildable caches get different recommendations. A cache is never treated as an automatic replacement for the source of truth.

The directory and expanded provider rules were reviewed against official documentation on September 8, 2026. Provider preferences change candidate selection where an appropriate offering is covered. An existing engine is preserved unless the result explicitly identifies compatibility work; single-node and self-operated choices are not silently replaced with managed-only services. Requirements that the selected candidate does not establish are called out for resolution.

Some inputs change operational advice rather than the database name. A budget preference does not establish affordability; a consistency label does not configure the database. Document transaction boundaries, isolation, read routing, and failure behavior in a prototype.

Recommendations are editorial judgments. Test the named candidate and its alternative against your real query patterns, write concurrency, regional latency, recovery targets, and total cost. We do not provide numerical fit scores because these broad inputs cannot justify that precision.

Who writes this, and how?

The guides are published under the Databases.how editorial name. This edition was prepared with AI assistance and reviewed against primary documentation on September 7, 2026. No individual expert credentials, independent performance benchmarks, or external technical certifications are claimed.

Each guide links to the documentation behind it, labels hypothetical examples, and supplies practical steps or a worksheet. Product behavior can depend on version, configuration, extensions, hosting plan, and region. Check those details before using guidance in a production decision.

Reading times are calculated from article text and examples at 200 words per minute. They describe reading, not the time needed to complete an experiment or restore drill.

The readiness checklist is a self-assessment. Its ten checks carry equal weight for progress tracking; a complete count is not proof that a system is safe or ready to launch. Keep evidence for each answer. Checklist progress is stored in this browser, and you can download it without creating an account.

This edition includes no paid placements or affiliate links. Source links are supplied so you can inspect the underlying claims and their limitations.

Primary documentation

Sources consulted for this edition and linked in context from the selector or guides. This is a reading list, not a product ranking.