If I'm buying an office PC for email and browsing, I want an SSD, a responsive processor, and enough memory to keep my usual apps open. For that job, I'd start with 16 GB and consider 32 GB if the work calls for it. An RTX 5090 would be an impressive piece of hardware to check my email on. It wouldn't make the email any better.

I look at cloud infrastructure the same way. If the job is to get a company website online and let the team update it, a simple managed hosting plan may do everything I need. I can get to market quickly, see how people use the site, and revisit the setup when I have a reason to.

On October 28, Alphabet reported that its cloud division's quarterly revenue had more than doubled to $30.7 billion. The company also reported $51.4 billion in quarterly capital spending, primarily on technical infrastructure. Most businesses are making a much smaller decision, but the question is familiar: how much capacity do you pay for now, and how much do you add when the demand shows up?

Size for the next three months

Before I pick a server or a database edition, I ask three questions:

  1. What are we supporting today? How many customers use the system, what do they do, and when is it busiest?
  2. Where will we most likely be in three months? That's the workload I want the setup to handle comfortably.
  3. What if we beat that forecast? I want to know what I'll change, who'll make the change, and how long it'll take.

That's how I decide whether automatic scaling is worth setting up on day one. If another server spins up when traffic rises, I want to know that it will actually solve the slowdown. If the database is the bottleneck, paying for another web server may leave customers waiting just as long.

The same thinking applies to software licenses. SQL Server 2025 Enterprise can create and rebuild indexes online, while Standard doesn't support that feature (Microsoft's edition comparison). If I can schedule the maintenance during a quiet window, Standard may be enough. If customers need uninterrupted access while that work happens, Enterprise has a feature I can put a value on.

Count the cost of the move and the cost of running it

I'd put the hosting bill next to the costs that tend to sit outside it: licenses, moving and testing the data, time spent running both systems, and the work of maintaining the new setup. A low monthly quote can look different once you know who's responsible for backups, upgrades, and problems after launch.

Two things make me revisit a setup. The first is customer experience. If the site repeatedly slows down at busy times, I look for what's making customers wait. The second is the risk of losing data. If I can't restore a backup reliably, I have work to do even if the site is fast.

Make deployment, backups, and rollback easy from day one

Even on a simple setup, I want automatic database backups and a restore I've actually tested. I also want a repeatable way to deploy code and get back to the previous working release. If a release changes the database, I want to know how we'll recover from that change while preserving new customer activity. Rolling back the code only gets me part of the way there.

I'm comfortable starting with a modest setup when I know how to recover from a bad release and what I'll do if we grow faster than expected. Then I can spend money on the upgrade when I know what it buys.