A hyperscaler is a cloud provider operating at a scale where infrastructure is designed rather than bought: custom silicon, purpose-built data centres, private global networks, and a service catalogue in the hundreds.
There is no formal threshold and the term is not a standard. What it describes in practice is a small group of providers whose scale changes what they can offer, and the interesting question is not the definition but whether that scale is doing anything for you.
For a genuinely large or unusual workload it is doing a great deal. For a web application and a database, a substantial part of what you are paying for is optionality you will never exercise, and the complexity that comes with it is a real cost.
Table of contents
- What the scale actually buys
- The cost of the catalogue
- The tests that actually decide it
- The cost comparison people get wrong
- A reasonable default
- How this fits the rest of the stack
- FAQ
What the scale actually buys
Four things are genuinely only available at this size, and they are worth knowing so you can tell whether you need them.
- Global footprint. Dozens of regions with multiple isolated availability zones each. If you have a regulatory requirement to keep data in a specific country, or genuinely global users needing local latency, this is difficult to replicate.
- Custom hardware. Purpose-designed processors, accelerators and networking. For machine learning training, high-performance computing, or anything needing specific accelerators at volume, the alternatives are limited.
- Elastic capacity. The ability to absorb an enormous, sudden increase without a conversation. Genuinely valuable if your load is spiky by orders of magnitude, and irrelevant if it is not.
- Service breadth. Hundreds of managed services covering nearly every category. This is the headline feature and the most double-edged.
The honest framing: these are real capabilities and most applications use none of them. A web service with a database and a queue is served by all four properties in exactly the same way it would be served by a much smaller provider, which is to say not much.
The cost of the catalogue
Service breadth is sold as an advantage and it carries a price that does not appear on the invoice.
A learning surface. The identity and access model alone is a specialism. Networking is a specialism. The billing model is a specialism. Teams routinely hire for these, which is a real cost that never shows up in a cost comparison against a simpler platform.
Configuration risk. More knobs means more ways to be wrong, and the well-known incident pattern here is a storage bucket made public during debugging. The complexity is the vulnerability.
Unpredictable billing. Per-request charges, per-gigabyte charges, cross-region transfer, requests against your own data. A bill that is difficult to predict in advance is difficult to control, and the classic version of this is discovering that inter-region transfer between two services you own is a significant line.
Architectural pull. The managed services are convenient and proprietary. A system built deeply on one provider’s queue, function runtime, identity and datastore is expensive to move, and that is a strategic position worth choosing deliberately rather than arriving at.
None of this makes the choice wrong. It makes it a choice, with costs that are mostly in attention rather than in money.
The tests that actually decide it
Rather than comparing feature lists, answer these five questions about your own workload.
- Does your traffic vary by an order of magnitude, unpredictably? If yes, elasticity is worth real money. If your load is a predictable daily curve, you are buying insurance against something that does not happen.
- Do you have a hard data residency requirement? A regulator naming a country makes region coverage a requirement rather than a preference.
- Do you need specific hardware? Accelerators for training, or unusual instance shapes. This is a genuine constraint or it is not, and it is easy to answer.
- Are you using managed services that have no equivalent elsewhere? Not services you could replace with a database and a queue, but ones doing something genuinely specific.
- Do you have someone whose job includes this platform? If nobody owns it, the complexity is unmanaged rather than absent.
Two or more clear yeses is a reasonable case. Five noes and a web application means you are likely paying, in money and in attention, for optionality you will not exercise.
The awkward middle case is worth naming: a team that answered no to all five, chose a hyperscaler anyway because it seemed like the responsible option, and now runs a Kubernetes cluster to serve an application that is one service and one database. That is a common and expensive place to be.
The cost comparison people get wrong
Comparing on instance price is how a stack ends up costing several times the estimate, because compute is frequently a minority of the bill.
The lines that are routinely missing from a comparison:
- Egress. Frequently the largest surprise. Data leaving the platform is metered, and cross-region transfer between services you own is metered too.
- Load balancers. An hourly charge per balancer plus a usage component, before any traffic.
- Managed database premium. The managed version costs substantially more than the equivalent instance, which is often worth it and should be counted.
- Storage operations. Not just gigabytes stored but requests against them, which for a chatty application can exceed the storage cost.
- NAT and gateway charges. Hourly plus per-gigabyte, easy to forget entirely.
- Support. A support plan with a meaningful response time is typically a percentage of spend.
- The person. The most expensive line and the one never included.
The honest exercise is to price your actual architecture on both sides, including every line above, rather than comparing a virtual machine against a virtual machine. On RunxBuild the general ladder runs from a $4 Dev plan through to larger plans, with static sites including 120GB of bandwidth before $0.10/GB applies, and the RunxBuild hosting calculator totals it including the database and storage.
A reasonable default
The position that serves most teams: start on the simplest platform that runs your application, and move when a specific requirement forces it.
This is the opposite of the usual advice to build for scale from day one, and the reason is that architecting for a scale you do not have costs you velocity now in exchange for flexibility later, and most projects need the velocity more.
What makes this safe rather than reckless is keeping your application portable in the ways that are cheap:
- Containerised or built from a repository, so it runs anywhere.
- Configuration in environment variables rather than baked into a platform’s format.
- A standard database, meaning Postgres or MySQL rather than a proprietary datastore.
- Object storage behind an interface you control.
- Infrastructure that is documented, so recreating it is a task rather than an archaeology project.
An application with those properties can move when a requirement appears. One built deeply on a proprietary function runtime and identity model cannot, and that is the decision that is expensive to reverse, not the choice of provider.
The services documentation covers the runtimes available on RunxBuild, and managed MySQL and Postgres are the databases, which is deliberately the portable choice.
How this fits the rest of the stack
The useful comparison is never provider against provider, it is your actual architecture priced completely on each, including egress, load balancing, storage operations and the hours somebody spends operating it. The RunxBuild hosting calculator totals the simpler side across services, databases, storage and bandwidth, which is the number worth having before deciding that scale you are not using is worth paying for.
Useful related references:
FAQ
What is a hyperscaler?
A cloud provider operating at a scale where it designs its own infrastructure rather than buying it: custom silicon, purpose-built data centres, private global networks and a catalogue of hundreds of managed services. There is no formal threshold; the term describes a small group of the largest providers.
Do I need a hyperscaler for my application?
Probably not for a web application with a database. The distinguishing capabilities are global region coverage, custom hardware, extreme elasticity and service breadth. If your traffic is predictable, your data has no residency requirement and your hardware needs are ordinary, you are paying for optionality you will not use.
Why are hyperscaler bills so hard to predict?
Because pricing is granular and multi-dimensional: per request, per gigabyte stored, per gigabyte transferred, per hour for gateways and balancers, and cross-region transfer between services you own. Each line is small and comprehensible; the total is difficult to model before you have run the workload.
What is vendor lock-in and does it matter?
It is the cost of moving away, and it varies enormously by what you use. Compute and standard databases are portable. Proprietary function runtimes, identity models and datastores are not. Keeping the portable parts portable is cheap; discovering after two years that your architecture cannot move is not.
Should I start on a hyperscaler in case I need to scale?
Usually not. Architecting for a scale you do not have costs velocity now for flexibility later, and most projects need the velocity more. Start simple, keep the application containerised with configuration in environment variables and a standard database, and move when a specific requirement forces it.