Skip to content

The cloud stack has seven levels now, it's not just IaaS, PaaS, SaaS

Every course still teaches three boxes: IaaS, PaaS, SaaS. The market stopped matching that picture about eighteen months ago.

The old diagram was good. It answered one question well: how much of the server is my problem? Rent a machine and all of it is yours. Push code to a platform and most of it is theirs. Buy finished software and none of it is yours.

Then three things happened. The middle of the stack collapsed into itself. The database turned into a separate market with billions of dollars moving through it. And a new level appeared, one that exists because AI agents now write code that has to run somewhere.

Here is the picture I would draw instead. Two stacks, not one, and SaaS in neither of them.

Three levels became seven, and a second stack appeared next to it
Where code runs and where data lives are two separate purchases.
Where code runs
Agent sandboxesnewE2B, Modal, Daytona
Edge isolatesCloudflare Workers
FaaS platformsLambda, Vercel
Serverless containersnewCloud Run, Fargate
Managed KubernetesEKS, GKE, AKS
IaaSEC2, Compute Engine
Bare metalHetzner, Equinix
Where data lives
Backend as a servicenewSupabase, Firebase
Serverless databasenewNeon, Aurora Serverless
Managed databaseRDS, Cloud SQL
Database on a clusterCloudNativePG operator
Database on a VMPostgres you patch
Taught in 2019: IaaS, PaaS, SaaS. Everything above sat inside two of those boxes, or in neither.

Notice SaaS is in neither stack. That was always the odd one out. SaaS is software you buy. The rest are places you run software you wrote. Putting them in the same diagram confused a generation of students.

Change one: PaaS and functions collapsed into each other

The old rule was simple, and for years it was true.

  • A PaaS app is a program that stays running. It sits there waiting. You pay by the hour, all day, even at 3am when nobody is awake. Think of a shop that keeps the lights on.

  • A function is not a program that stays running. It wakes up when a request arrives, does the work, and goes back to sleep. You pay per request. Think of a vending machine.

So: warm means pay by the hour, cold means pay per request. Two neat options.

Both of those have now moved, from opposite directions.

Vercel's Fluid compute lets one instance handle many requests at the same time, and bills you for CPU only while your code is actually running. If your code is sitting there waiting on a database or an AI model to reply, the CPU meter pauses. Nothing is charged between requests at all. The rates are $0.128 per CPU-hour and $0.0106 per GB-hour of memory. That is a warm, long-lived process billed like a function.

Coming the other way, Google Cloud Run takes a plain Docker container, gives it full Linux, any language you want, up to 32 GB of memory and a 60 minute timeout, and still scales it to zero. That is a function-shaped bill wrapped around a real server.

What you actually pay for, second by second
One minute of a quiet afternoon, three requests in it, three billing models. Filled means billed.
Always-on serverVM, Kubernetes, Heroku
$$$$$$$$
Classic functionLambda, billed on wall clock
$$$$
Active CPUVercel Fluid compute
$
The gaps in the third row are the time each request spends waiting on a database or a model. The dollar signs are relative, not real prices.

The same three requests, billed three ways. "Is it warm?" and "how am I billed?" used to be one question. They are now two, and you can get any combination of them.

Change two: "serverless" now means four different things

This is where most conversations go wrong. Someone says the team is going serverless, everyone nods, and three months later they discover the thing they picked cannot run a cron job.

Four things people mean by "serverless"
Same word, four sets of limits. Ask which one before you agree to it.
FunctionsLambda, Azure Functions
Runs
One short request handler at a time
Scales to zero
Yes, fully
The catch
A few minutes per request, and nothing survives between calls
Serverless containersCloud Run, Fargate
Runs
Any Docker image, any language, up to 32 GB and 60 minutes
Scales to zero
Yes, fully
The catch
Still one region unless you set up more yourself
Edge isolatesCloudflare Workers
Runs
JavaScript or WebAssembly, in every city at once
Scales to zero
Yes, and starts in under a millisecond
The catch
No full Node runtime, and a tight budget on CPU time
Serverless databaseNeon, Aurora Serverless
Runs
Postgres, with compute split away from storage
Scales to zero
Compute yes, storage never
The catch
Waking up takes time, and the bytes are billed while asleep

The four are not close relatives. A function times out in minutes. A serverless container runs for an hour. An edge isolate starts in under a millisecond but cannot run normal Node code. A serverless database sends its compute to sleep and keeps billing you for the bytes on disk.

Next time someone says serverless, ask which of the four. The limits are what you will be living with.

Change three: the money moved to the database

While the internet argued about Kubernetes, the actual capital went somewhere else.

Where the money went
$1BDatabricks pays for Neon, on about $25M of yearly revenue
$250MSnowflake takes Crunchy Data, reported
$2B → $5BSupabase valuation, in four months
55.6%Postgres usage, Stack Overflow 2025
80%of new Neon databases created by agents, not people

Databricks paid around $1 billion for Neon, a company selling serverless Postgres, on roughly $25 million of yearly revenue. Snowflake took Crunchy Data for a reported $250 million. Supabase went from a $2 billion valuation to $5 billion in four months. Postgres reached 55.6% usage in Stack Overflow's 2025 survey, the most used database two years running.

Prices fell hard afterwards. Neon's storage dropped from $1.75 to $0.35 per GB-month, an 80% cut, and compute came down too.

The reason is in that last number. Over 80% of Neon's new databases were created by AI agents, not by people, up from 30% a year earlier. An agent spinning up a throwaway database per task is a very different customer than a human clicking through a console once a quarter. Scale-to-zero Postgres exists because that customer exists.

And this is a second stack, not a level in the first one. Where your code runs and where your data lives are two separate purchases. The old diagram had no cell for a database, so nobody was taught to think of it that way.

The trap that comes from mixing the two stacks

Pick serverless compute and a normal managed database, and you will meet this on your first busy day.

The mismatch nobody warns you about
Your functions scale to a thousand. Your database does not.
Without a pooler
1,000 function instances
Postgresmax 100 connections
Requests fail"too many clients"
With a pooler
1,000 function instances
PoolerPgBouncer, RDS Proxy
Postgresthe same 100 connections, reused

Postgres defaults to 100 connections, and there is no clever code that fixes that arithmetic. You put a pooler in the middle or you take an outage.

Two more things worth knowing before you trust "scales to zero" on a database. Storage never sleeps: only the compute does, and a paused database still bills for every byte it holds. Waking up takes time: a sleeping database needs a moment to come back, and that moment lands on top of whatever cold start your function already had.

Then there is the asymmetry that decides how paranoid to be. Leaving your hosting platform is roughly a week of work. Leaving your database means moving terabytes, paying to get them out, and rewriting queries for a different engine. Be relaxed about compute lock-in. Be careful about data lock-in.

The new level: agent sandboxes for code the AI wrote

This is the genuinely new category, and it did not exist when anybody drew the original diagram.

An AI agent writes code. That code has to run. You cannot run it on your own server, because you did not write it and you do not know what it does. You need a disposable computer: one task, fully sealed off, thrown away afterwards.

That is now a product category with real competition in it. In April 2026 the OpenAI Agents SDK shipped sandbox support with seven hosted providers built in: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop and Vercel. Docker shipped an experimental sandbox feature of its own.

ProviderHow it is isolatedLongest sessionGPUCold start
E2BFirecracker microVMup to 24 hoursnoabout 90 to 200 ms
ModalgVisor containerno set limityes, T4 up to B200not published
DaytonaSysbox containerno set limityesabout 90 ms
Vercel SandboxFirecracker microVM45 min free, 24 h paidnonot published
Cloudflare Sandboxescontainer at the edge30 minutesnonot published
BlaxelmicroVMno set limitnoabout 25 ms

Vendor-reported numbers, and they move fast.

The differences are not cosmetic. Session limits run from 30 minutes to no limit at all. Cold starts run from about 25 milliseconds to a couple of hundred. Some give you a GPU and most do not. The isolation model differs too: hardware-level microVMs like Firecracker on one end, container-based isolation on the other. If you are running code you truly do not trust, that is the column to read first.

Why care if you are not building agents? Because of that 80% number from Neon. The fastest-growing consumer of cloud infrastructure right now is not a person. Every provider is being redesigned around a customer that appears in a burst, works for ninety seconds, and disappears. That changes the products you get offered, whoever you are.

How to choose: match the shape of the work to the level

Two questions instead of one. First, what shape is the work? Second, and separately, where does the data live?

Five answers, not two
Match the shape of the work, then choose the data layer as its own decision.
Small pieces of JavaScript that must feel instant in every country at once
Edge isolatesCloudflare Workers, Deno Deploy
A web app or API with bursty traffic that spends most of its time waiting on a database or a model
A functions platformVercel, AWS Lambda
Cron jobs, queue workers, long tasks, or any language you like
Serverless containersCloud Run, Fargate, Fly.io
Many services, private networking, steady traffic all day, and one person whose job is the platform
Managed KubernetesEKS, GKE, AKS
Code an AI wrote, one task at a time, that you cannot trust
An agent sandboxE2B, Modal, Daytona

Most teams get the first question roughly right by instinct and the second one wrong by default, because the old diagram never told them there was a second question.

What did not change at all

Two things are still entirely your job at every level, from bare metal to the newest sandbox.

Your schema and your queries. No provider in either stack will fix a missing index. A managed database doing a sequential scan over forty million rows is a slow database. Most "our managed database is slow" tickets are really a query nobody looked at.

Your bill. Every model here has a way of surprising you. Always-on servers charge you while you sleep. Functions charge you per request and the requests add up faster than anyone expects. Kubernetes charges $73 a month per EKS cluster before a single container starts, and jumps to about $438 if you let the cluster fall behind on versions. Serverless databases charge for bytes at rest. Nobody sends you a warning email.

The diagram in your slide deck is not wrong. It is just from a smaller market. Redraw it with two stacks and seven levels, and the arguments on your team get a lot shorter.

Every price and limit above links to its source: vendor documentation and pricing pages where one exists, press reporting for the acquisition figures. The sandbox table is compiled from vendor documentation and published benchmarks, which is why it carries "not published" in places. Checked in September 2026, and this market moves fast, so verify before you commit to anything.