SaaS means software you access over the internet and pay for by subscription, where the provider runs the infrastructure and you never install or update anything - and that delivery model forces a set of technical decisions that are the actually interesting part of the definition.
The definition takes one sentence and every glossary page gives it. What those pages skip is the consequence: once you deliver software this way, a series of architectural questions become unavoidable, and they are the same questions for every company that has ever built one.
Table of contents
- The definition, and the three properties that follow
- Multi-tenancy, the decision everything else depends on
- What the model demands that on-premise software never did
- The infrastructure shape underneath a typical one
- Buying one, briefly
- How this fits the rest of the stack
- FAQ
The definition, and the three properties that follow
Software as a service: the application runs on the provider’s infrastructure, users reach it over the network, and payment is recurring rather than a one-off licence. That is the whole definition.
Three things follow necessarily, and they are what separate SaaS from software that merely happens to be online.
- The provider operates it. Uptime, patching, scaling, and backups are the vendor’s problem. Customers do not have a version number, because there is one version and it is whatever is deployed right now.
- Updates are continuous and universal. There is no upgrade project. This is enormously convenient and it means you cannot decline a change you dislike.
- Data lives with the provider. Which raises export, residency, and retention as first-class questions rather than afterthoughts.
The related terms fit around it: IaaS rents you machines, PaaS runs your application, SaaS is finished software. The differences are just how much of the stack somebody else owns.
Multi-tenancy, the decision everything else depends on
The first real architectural question in building one of these is how customers share infrastructure, and the choice has consequences for years.
Shared database, shared schema. Every customer’s rows live in the same tables, separated by a tenant identifier. Cheapest to run and simplest to deploy, and it means one missing tenant filter in one query is a data breach. This is the most common model and it demands discipline enforced at the framework level rather than by developer memory.
Shared database, separate schema. One schema per customer in the same instance. Better isolation, straightforward per-customer export, and migrations that now have to run across N schemas.
Separate database per customer. Strong isolation, easy compliance story, easy export and deletion. Operationally heavy and expensive at small contract sizes, which is why it usually appears as an enterprise tier rather than as the default.
Most products start with the first and add the third for large customers who demand it. That is a reasonable path, and it is much easier if you designed the data access layer expecting it.
What the model demands that on-premise software never did
Delivering software as a service converts several things from optional to mandatory.
- Deploys have to be safe and frequent. There is one version and everyone is on it, so a bad release affects every customer simultaneously. That requires build logs, health checks, and a rollback that works, and it requires them before you need them.
- Observability is not optional. You cannot ask a customer to send you a log file. If you cannot see what happened inside your own system, you cannot support it.
- Migrations must run without downtime. Schema changes happen while customers are using the product. Additive changes, backfills, and switchovers become a routine skill rather than an occasional event.
- Tenant isolation is a security boundary. Every query touching customer data needs the tenant filter, and ‘we always remember’ is not a control.
- Data export has to exist. Because customers will ask, because contracts will require it, and because regulations may compel it.
The infrastructure shape underneath a typical one
Strip away the domain and almost every SaaS product has the same handful of pieces, which is reassuring if you are building your first.
A web application serving the interface. An API the frontend and any integrations call. A relational database holding customer records - Postgres or MySQL, because the data is relational and transactional and nothing exotic is warranted. Object storage for files and uploads. A background worker for anything slow, scheduled, or retryable: emails, exports, webhooks, billing runs. And somewhere to read logs and metrics for all of it.
That is six pieces and it is genuinely most of them. Products get complicated later, usually for good reasons, but a first version that has these six and does them properly is further along than one with a sophisticated architecture and no customers.
Buying one, briefly
From the other side of the transaction, the questions worth asking are short and rarely asked.
Can you get your data out, in a usable format, without contacting sales? What is the actual uptime commitment and what happens when it is missed? Where is the data stored, and does that satisfy whatever rules apply to you? What is the price at ten times your current usage, since that is the number that matters when switching becomes hard? And how are you notified of changes to functionality you depend on?
None of these are exotic. They are simply easier to ask before signing than after, which is the entire argument for asking them.
How this fits the rest of the stack
The six pieces above are the actual bill for a SaaS product, and they are easy to underestimate individually and expensive collectively. The RunxBuild hosting calculator puts the web service, the API, the database, the worker, the storage, and the bandwidth on one page so the running cost is visible before the first customer. RunxBuild deploys services from GitHub in Node, Next.js, Python, Go, Ruby, Java, and .NET, with managed MySQL and Postgres, persistent storage, deploy history, runtime logs, and autoscaling.
Useful related references:
- Application Service Providers: ASP, SaaS, MSP, and the Lineage
- Golang comparable: The Constraint That Changed Meaning in Go 1.20
- Math Domain Error Explained: Meaning and How to Debug
- Services on RunxBuild
FAQ
What does SaaS mean?
Software as a service: an application you use over the internet on a subscription, where the provider runs the infrastructure and you never install or upgrade anything. There is one version, updated continuously, and your data lives on the provider’s systems.
What is the difference between SaaS, PaaS, and IaaS?
How much of the stack somebody else owns. IaaS rents you virtual machines and you manage everything above the hypervisor. PaaS runs your application from your code and manages the OS, runtime, and build. SaaS is finished software where you manage nothing but your own data.
What is multi-tenancy?
How a SaaS product shares infrastructure between customers. The three models are a shared database with a tenant column, a shared database with a schema per customer, or a separate database per customer. Each trades operational cost against isolation strength, and the choice shapes migrations and compliance for years.
What infrastructure does a SaaS product need?
Usually six things: a web application, an API, a relational database, object storage for files, a background worker for slow or scheduled tasks, and somewhere to read logs and metrics. Most first versions need exactly that and nothing more.
What should I ask before buying a SaaS product?
Whether you can export your data in a usable format without contacting sales, what the uptime commitment actually is, where the data is stored relative to your compliance rules, what the price looks like at ten times your current usage, and how you are told about changes to features you depend on.