Database selection framework: workload evidence before product choice

Database selection is a constraint-matching and measurement problem, not a table of user-count or dataset-size thresholds. Start with access patterns, invariants, consistency, failure objectives, deployment constraints, team operations, and migration cost. Only then shortlist systems and run representative correctness and load tests.

A system may support transactions, JSON, indexes, graph queries, vector search, or columnar analytics with different scopes and costs. Product categories overlap; capability must be checked in the current official documentation and proved for the exact query and failure path.

Модель и предпосылки

• Hard gates reject a candidate before performance scoring: required isolation, data residency, backup/restore, supported query semantics, and operability.
• Benchmarks replay production-shaped key skew, data distribution, concurrency, failure, recovery, and tail latency; vendor headline numbers are not acceptance tests.
• The chosen design includes an exit path: canonical data ownership, export/restore test, schema evolution, and a reversible migration plan.

Проверяемые утверждения

• C1. Serializable transactions are a scoped database capability; they must be matched to application invariants and retry behavior.
• C2. DynamoDB tables and LSIs can serve strong reads, while GSIs and Streams are eventually consistent.
• C3. Neo4j shortest-path planning depends on endpoints, predicates, and operator choice; graph storage is not a universal complexity shortcut.
• C4. Qdrant combines vector and payload indexes; filtered ANN requires both modeling and recall/latency evaluation.
• C5. DuckDB is an in-process analytical engine with columnar-vectorized execution, not a general network OLTP replacement.

Исполняемые сценарии

Transactional invariant gate. A candidate must preserve the actual concurrent invariant and expose a workable retry contract before latency is scored.

Key-value access-pattern fit. Known partition-key reads may fit a key-value store, but secondary-index and consistency semantics remain explicit.

Graph and vector evidence. Traversal shape and ANN recall are measured separately; neither product label proves the workload.

Embedded analytics boundary. An in-process OLAP engine is selected for local analytical scans, not assumed to be a multi-service OLTP authority.

Reversible decision and re-test. Restore, export, migration, and workload-drift triggers are part of selection, not post-launch paperwork.

Ошибки проектирования

• Не выбирайте database по числу пользователей, гигабайтам или «стартап/enterprise» без workload и SLO.
• Schemaless не означает отсутствие schema: validation, indexes, migration и compatibility просто переходят в другие слои.
• Наличие ACID не означает, что multi-service dual write атомарен, а наличие JOIN не гарантирует хороший план для конкретной модели.
• Не сравнивайте managed price по одной единице: учитывайте replicas, indexes, egress, backups, operations и idle/peak profile.

Границы гарантии

• Framework не объявляет одного победителя: один продукт может быть system of record, другой — производной search/analytics projection.
• Полиглотность оправдана только с явным ownership, replication lag semantics, rebuild и incident runbook.
• Все числовые пределы и цены должны быть датированы и проверены перед решением; в уроке нет универсальных cutoffs.

Связанные материалы

Официальные и первичные источники

1. PostgreSQL: Transaction Isolation
2. Amazon DynamoDB: Read consistency
3. Neo4j Cypher: Shortest paths
4. Qdrant: Indexing
5. DuckDB: Why DuckDB