The cloud stack has seven levels now, it's not just IaaS, PaaS, SaaS
Every course still teaches three boxes. The market moved on about eighteen months ago.
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 boxes on the left. Seven levels and a second stack on the right.
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.
Solid blocks are billed. Dashed blocks cost nothing. 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.
Same word, four sets of limits. Ask which one before you agree to it.
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.
Five numbers from eighteen months of the database market.
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.
Your functions scale to a thousand. Your database does not.
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.
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?
Match the shape of the work, then choose the data layer as its own decision.
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.
Originally published at arifulislamat.com.
Top comments (0)