SaaS vs PaaS: where the line is, with real examples
PaaS runs your code; SaaS runs the vendor's. Who manages what, eight real products classified, and a cost example for a small internal app.
You need a small internal tool, say an approval form for purchase requests, and a colleague asks whether you want a SaaS product or “something on a PaaS”. You want the difference in one line. With PaaS (platform as a service) you bring the application code and the provider runs everything underneath it. With SaaS (software as a service) the provider brings the code too, and you only use the finished product.
The line matters because it decides who writes, fixes and updates the application, and that is where most of the cost hides. For the full definition of SaaS, see What is SaaS?; for how SaaS reaches you over the network, see SaaS in cloud computing.
PaaS and SaaS in plain terms
Think of food. Renting a fully equipped commercial kitchen by the hour is PaaS: the owner keeps the ovens, gas and cleaning running, and you bring the recipe and cook. Ordering from a restaurant is SaaS: the recipe, the cooking and the kitchen are theirs, and you choose from the menu.
The US National Institute of Standards and Technology draws the same line in SP 800-145. PaaS lets you deploy “consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.” SaaS gives you “the provider’s applications running on a cloud infrastructure.” In both, you do not manage the servers or the operating system. The difference is whose application it is.
Who manages what
Microsoft publishes a shared responsibility matrix for its cloud. The rows below are its PaaS and SaaS columns, with one row added from the NIST definitions: who writes the application code.
| Responsibility | PaaS | SaaS |
|---|---|---|
| Application code | You | Provider |
| Customer data, settings, identities | You | You |
| Applications (configuration, access) | Shared | Shared |
| Network controls | Shared | Provider |
| Operating system, hosts, data center | Provider | Provider |
Two rows stay with you in every model: your data and who can sign in. Microsoft states it directly: “For all cloud deployment types, you own your data and identities.” Moving from PaaS to SaaS hands over the code and the network controls, not your data.
Eight real products, classified
Microsoft’s own page names several of its products as PaaS or SaaS examples, which makes the boundary easy to see inside one vendor. The table adds three products from other vendors.
| Product | Model | You bring | Source of the classification |
|---|---|---|---|
| Azure App Service | PaaS | Web app code | Microsoft |
| Azure Functions | PaaS | Function code | Microsoft |
| Azure SQL Database | PaaS | Schema, queries, data | Microsoft |
| Heroku | PaaS | App code, add-on choices | Heroku docs: you deploy your own code |
| Microsoft 365 | SaaS | Users, settings, content | Microsoft |
| Dynamics 365 | SaaS | Users, settings, records | Microsoft |
| Google Workspace | SaaS | Users, settings, content | Google Workspace as SaaS |
| Salesforce sales applications | SaaS | Users, settings, records | Runs Salesforce’s code; you configure it |
A database service sits in the PaaS column even though you write no application code for it. You still design the schema and the queries, which is your code in another form. That is a useful test: if you are writing logic that the provider will run, it is PaaS.
Worked example: an internal app on PaaS vs a SaaS tool
Heroku publishes its prices in its usage and billing documentation (as of October 2026): “a Basic dyno costs US$7 per month” and “an Essential-0 Heroku Postgres database costs US$5 per month,” prorated to the second.
Example: you need a purchase-approval tool. Option A is a small app you build and run on Heroku. Option B is a SaaS approvals tool. The SaaS price and the maintenance time are assumptions for illustration; the Heroku prices are published.
- Option A hosting: one Basic dyno ($7) + one Essential-0 database ($5) = $12 a month.
- Option A maintenance: 4 hours a month of a developer’s time (fixes, updates, security patches) at $75 an hour = $300 a month.
- Option A total: $12 + $300 = $312 a month, whatever the number of users.
- Option B: a SaaS tool at $10 per user per month. For 10 users, 10 x $10 = $100 a month. For 50 users, $500 a month.
- Break-even: $312 / $10 = 31.2 users. Up to 31 users the SaaS tool costs less; from 32 users, the PaaS app does, if the maintenance estimate holds.
Hosting is 4% of Option A’s cost ($12 of $312). The developer’s time is the real price of PaaS, which is why the hosting line alone misleads.
The platform can change under you
A PaaS carries a risk that a spreadsheet does not show. On February 6, 2026, Heroku announced that it “is transitioning to a sustaining engineering model focused on stability, security, reliability, and support,” and that enterprise contracts “will no longer be offered to new customers.” Customers paying by credit card can continue to use it.
Your app keeps running in that situation, but the platform’s roadmap is no longer growing, and your code is written for it. SaaS has the same risk in a different shape: the vendor can change or retire the product. In both models, ask what an exit would cost before you start.
Common mistakes
- Comparing hosting fees and ignoring maintenance. On PaaS you own the code, so you own its bugs and updates. Why it happens: the hosting price is the only number on the pricing page. Instead: add developer hours, as in the example, before you compare with a SaaS subscription.
- Thinking PaaS means no security work. Your data, identities and application configuration stay yours in both models, per Microsoft’s matrix. Why it happens: “the provider manages the servers” sounds like “the provider handles security”. Instead: list the rows that stay with you and assign each one an owner.
- Classifying by vendor instead of by product. One company can sell SaaS and PaaS side by side, as Microsoft and Salesforce do. Why it happens: the brand is easier to remember than the product. Instead: ask, for each product, whose code runs.
- Building on a PaaS for a job a SaaS tool already does. Custom code is worth it when the workflow is yours alone. Why it happens: a small app looks cheap to build. Instead: check the break-even user count, then decide.
Sources
- NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
- Microsoft, Shared responsibility in the cloud, checked October 2026.
- Heroku, Usage and billing, checked October 2026.
- Heroku, An update on Heroku, February 6, 2026.
In three sentences
PaaS runs code you write on infrastructure the provider manages, while SaaS runs the provider’s own finished application for you. In both models your data, your identities and your settings remain your responsibility. When you compare the two, count the developer hours a PaaS app needs, because hosting is often the smallest part of its cost.
Frequently asked questions
Is Salesforce SaaS or PaaS?
Both, depending on the product. Its sales and service applications are SaaS: you log in and use them. Salesforce also sells a platform for building your own applications on its infrastructure, which is PaaS, and it owns Heroku, a PaaS for general web applications.
Is serverless computing PaaS?
Usually, yes. Microsoft lists Azure Functions, its serverless service, as a PaaS example: you deploy code and the provider runs the servers, operating system and scaling. You still write and maintain the code, which is what separates it from SaaS.
