The data model is the one decision that gets harder to change every single week. Application code can be rewritten in an afternoon; a schema with three years of production data in it cannot.
Tuning a query is worth an afternoon. Fixing the model underneath it is worth a year — which is why we start at the schema and work outwards.
Normalised where correctness matters, denormalised where reads demand it, with constraints in the database rather than hopes in the application.
Finding the handful of queries responsible for most of the load, and the missing index behind the page everyone says is slow.
Schema changes that run against a live table without locking it, and roll back cleanly when the deploy behind them is reverted.
An honest answer rather than a preference. Most products need a relational core; some workloads genuinely don't, and we'll say which yours is.
Read replicas, failover, and the replication lag your application has to tolerate — decided before it surfaces as a bug report.
Point-in-time recovery, and a restore that has actually been rehearsed. An untested backup is a hope, not a plan.
Every one of these is a reasonable shortcut on day one and a serious project by year three. The cost of fixing them only ever goes up.
Replication, failover, and backup all depend on what's underneath them — cloud application development. Reporting workloads belong somewhere separate — data warehouse and BI.
New product or one already carrying years of data — send us the schema and the queries that hurt. We'll come back with what to change and what it costs to change it now versus later.