database-engine-selection-and-migrationlisted

# Database Engine Selection and Migration ## Purpose Make the accepted trade-offs and non-portable assumptions visible before an engine choice or cutover. Start with vetoes and behavioral proof, not a weighted feature popularity score. ## Decision inputs For an existing system, establish the outcome requiring change and whether migration or its destination is already mandated. If the choice remains open, include retaining the current engine as a baseline and assess whether a targeted query/index, configuration or supported-version change meets the same success criteria. Route unexplained slowness to `database-performance` before treating migration as its remedy; reuse accepted decisions when the target is fixed. ```text read/write/admin SLOs, availability, RPO/RTO, retention, and growth: OLTP/analytic/hybrid workload, data shape/distribution, working set, and peak concurrency: transaction invariants and anomalies the domain permits or forbids: topology, regions, replication/CDC, backup/restore, and failover requirements: required SQL/types/extensions/indexes/search/JSON/partitioning/columnar capabilities: JDK, ORM, pool, exact driver versions, batching/fetch/generated-key behavior: edition/license/managed-service constraints and team operational competence: DDL/cutover window, reversibility, data sovereignty, and exit cost: ``` If these are missing, produce the evidence plan rather than selecting a winner. Inspect build/toolchain, resolved dependencies and runtime image