How WhatDbShouldIUse works.

Database selection is a constraint problem

• Not a feature comparison problem
• Each database optimizes different trade-offs
• 15 scored dimensions (grouped into a 3-tier “genome”)
• Tier 1 (Functional DNA): Sovereignty, Multi-model, Consistency, Integrity, Governance
• Tier 2 (Operational DNA): Throughput, Latency, Elasticity, Query Depth, Schema
• Tier 3 (Workload DNA): AI / RAG, HTAP, Streaming, Lifecycle, FinOps
• Optimizing one dimension degrades another
• This trade-off surface is architectural friction

Step 1: Guided questions (signals → priorities)

• You answer a short sequence of scenario questions
• Each answer boosts priority weights for the dimensions it “owns”
• Example signals captured:
• Correctness vs tail-latency preference
• Managed vs self-hosted posture
• Geo-topology expectations
• AI / semantic retrieval importance

Step 2: Review + optional tuning

• After the questions, you get a Review step
• All 15 dimensions have sliders with priorities from 0–5
• Tuning is optional—use it only if a dimension feels overstated or understated
• If you change earlier answers, manual tuning resets to keep the flow consistent

Step 3: Unlock rule

• The tool waits for enough signal before showing a recommendation
• The recommendation unlocks after 2 non-skip answers
• Skipped questions don’t count toward the unlock threshold

Step 4: Scoring (weighted fit, then friction penalties)

• Each database has a 0–10 score for every dimension
• Priorities (0–5) weight those scores into an overall fit percentage
• Some dimension pairs trigger explicit friction penalties when both priorities are high
• Trade-off rules activate when both linked dimensions are prioritized above 3/5

Step 5: Results (shortlist + context)

• You get a ranked shortlist (not a single “best database”)
• Results include: why it fits, cautions, and close alternatives
• The “Decision shape” graph shows up to 8 active dimensions for readability

Workload classification

• Early questions implicitly identify the dominant workload shape
• Common shapes include:
• OLTP (transactional)
• Real-time systems
• Streaming / event-driven
• AI / semantic retrieval
• Analytics on operational data
• This shifts which dimensions get prioritized the most

Dimension weighting

• Weights are derived from the guided answers, then optionally tuned
• There is no fixed “one size fits all” scoring preset
• Examples:
• AI systems → AI / RAG + Multi-model
• OLTP systems → Consistency + Query Depth
• Analytics patterns → HTAP + Streaming (when ingestion/serving are coupled)

Scoring dimensions

• Each database evaluated across dimensions
• Dimensions scored (all 15):
• Tier 1: Sovereignty, Multi-model, Consistency, Integrity, Governance
• Tier 2: Throughput, Latency, Elasticity, Query Depth, Schema
• Tier 3: AI / RAG, HTAP, Streaming, Lifecycle, FinOps
• Note: the results “Decision shape” graph visualizes up to 8 of the currently active (non-zero) dimensions, and needs at least 3 active dimensions to render.

Trade-off penalties (architectural friction)

• Handles conflicting requirements explicitly
• Does not average incompatible dimensions
• Examples:
• Strict consistency vs sub-10ms p99 latency
• HTAP analytics vs max OLTP throughput
• Cryptographic integrity vs max write throughput
• AI / RAG readiness vs FinOps efficiency

Not a single answer

The system does not return a “best database”.

It returns a shortlist ranked by workload fit and constraint alignment.

Includes trade-offs

Each recommendation includes context; why it fits, where it breaks, and what alternatives exist.

This allows engineers to make informed decisions instead of blindly following rankings.