iQIYI Database Selection Tree

The value of a database selection tree is not that it picks a winner automatically. Its value is that it forces engineers to ask the right questions about workload before adopting a storage engine. The iQIYI example is useful because it reflects a large platform choosing different databases for different jobs instead of searching for one universal solution.

Start with the workload, not the brand name

A good decision tree begins with access patterns. Do you need multi-row transactions, joins, and strong relational integrity? Are you serving very low-latency key lookups? Is the data model flexible and document-shaped? Are you running large analytical scans over historical data? Each of those questions points toward a different class of system.

In that framing, MySQL fits transactional workloads with familiar relational modelling, strong tooling, and predictable SQL semantics. Redis fits hot-path serving for caches, counters, short-lived state, and other cases where latency matters more than full durability on every operation. TiDB and other distributed SQL systems try to preserve a relational model while scaling across nodes. Document stores such as Couchbase are comfortable when denormalised access and flexible schemas are acceptable. Analytical engines such as Hive or Impala are built for scanning and aggregation, not request-path OLTP traffic.

The tree encodes tradeoffs

The important questions in a selection tree usually sound like this:

• What are the dominant read and write patterns?
• What consistency guarantees are non-negotiable?
• Do we need joins, secondary indexes, or only key access?
• Is the pressure about latency, throughput, scale, flexibility, or analytics?
• Can the team operate the system confidently at production scale?

The last question is easy to skip and expensive to ignore. A theoretically perfect database that the team cannot debug, back up, or upgrade safely is the wrong choice.

Why multiple databases are both powerful and costly

Specialisation can produce better results. A cache should not pretend to be a warehouse, and a warehouse should not sit on the request path. But every additional database multiplies migration paths, failure modes, backup procedures, monitoring needs, and on-call burden. Polyglot persistence is an optimisation, not a badge of sophistication.

The useful lesson

A database selection tree should narrow uncertainty, not justify a favourite tool. If the workload is transactional and relational, start there. If the problem is hot reads, caching may be better than inventing a new primary store. If scale is the concern, ask whether schema, indexing, or query design should be fixed before moving to a more complex system.

The best teams treat database choice as an operational fit decision. The tree helps them make that decision consistently under pressure.

Seen that way, the decision tree is less about products and more about failure containment. A cache can fail differently from a transactional store, and an analytics engine can degrade differently from a serving database. Clear selection boundaries stop those failure modes from bleeding into every workload at once.