6. Database Selection and Indexing

Relational databases are strong defaults when transactions, constraints, joins, and structured relationships matter. They can scale substantially with good schema design, indexes, read replicas, and partitioning.

Document databases fit aggregate-oriented records with flexible structures and access patterns that can be served without many joins. They still require schema discipline and careful index design.

Key-value databases fit direct key-based lookups, sessions, and simple high-throughput access patterns.

Wide-column databases can support large distributed workloads when access patterns and partition keys are well understood.

Graph databases are useful when traversals across relationships are central to the product.

Search indexes support full-text search and relevance ranking; they are commonly derived from authoritative data stores and may update asynchronously.

Indexing rules

  • Index fields used in frequent filters, joins, and sorting.
  • For compound indexes, reason about field order and the actual query predicates.
  • Indexes speed up supported reads but add storage and write-maintenance cost.
  • Inspect query plans rather than guessing.
  • Avoid indexing every field by default.

Replication versus partitioning

  • Replication keeps copies of data for redundancy and read distribution.
  • Partitioning divides data across nodes to distribute storage and load.
  • Sharding introduces routing, rebalancing, cross-shard queries, and operational complexity.

Decision rule: choose the simplest database that satisfies correctness and access-pattern requirements. A popular database is not automatically the right database.

Key Takeaways
  • Select a database based on data relationships, transactions, and access patterns.
  • Indexes have both benefits and costs.
  • Replication and partitioning solve different problems.
  • Search indexes are often derived views, not the authoritative source.