[lumost]

The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori.

The following questions are likely to come up

1) My t3.xl DB is down, how much bigger can I make it?

2) My r3.24xl DB can only handle 100 TPS and now my site is down, what can I do?

3) My 2x r3.24xl DB cluster costs a lot of money, Are other solutions cheaper?

4) My latency is high, are other solutions faster?

For someone who hasn't dealt with these questions before, these will become long and painful lessons with massive material impacts to the business.

It's appealing to use Dynamo as it takes the magic out of scaling. It's appealing to use serverless RDBMS as you don't have to think about it anymore unless it has high costs/latency.

[mdekkers]

> The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori.

The answer is very clear-cut:

Work with professionals.

[lumost]

The number of professionals who know and care about scaling who also want to work on small scale applications is relatively small. Hiring them will pose a challenge.

[mr_toad]

The amount of data being collected in the world is growing much faster than the number of database engineers is.

[Groxx]

Why would you assume that the person responsible for a thing doesn't know what they're doing?