SaaS (software as a service) is the cloud service model in which a provider operates a complete, ready-to-use application and customers access it over the internet, usually through a browser or API, under a subscription or usage-based fee. Among cloud fundamentals, SaaS is the top layer of the classic stack above IaaS and PaaS: the customer manages users, data and configuration, while the provider manages everything underneath.
Email, office suites, customer relationship management, payroll and collaboration tools are typical SaaS products. The defining feature is not the browser interface but the division of responsibility: the customer consumes a service and does not install, patch or scale the software.
How SaaS delivers an application
A SaaS provider runs one codebase on infrastructure it controls, often a public cloud, and serves many customers, called tenants, from that shared platform. Releases are deployed centrally, so every tenant runs the same current version, and new features or fixes reach all customers without local upgrades.
The architecture behind the service is usually multi-tenant: tenants share application servers and often databases, with isolation enforced by tenant identifiers, separate schemas or separate databases. The isolation model shapes cost, performance predictability and how easily a provider can meet data residency and compliance requirements.
| Model | How data is separated | Typical trade-off |
|---|---|---|
| Shared database, shared schema | Tenant ID column on every row | Cheapest, relies entirely on correct application logic |
| Shared database, separate schemas | One schema per tenant | Better isolation, more migration effort |
| Database per tenant | Dedicated database instance | Strong isolation, higher operating cost |
| Single-tenant deployment | Dedicated application stack | Maximum control, behaves like managed hosting |
SaaS compared with IaaS and PaaS
The three service models differ in where the line of responsibility falls. Moving from IaaS to PaaS to SaaS, the customer gives up control in exchange for less operational work, a pattern often described as the shared responsibility model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical hardware and network | Provider | Provider | Provider |
| Operating system and patching | Customer | Provider | Provider |
| Runtime and middleware | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Data, users and access settings | Customer | Customer | Customer |
The last row is the crucial one. Even in SaaS, the customer remains responsible for who has access, how data is classified and whether it is backed up beyond what the provider guarantees. Many SaaS security incidents stem from weak customer-side configuration rather than from flaws in the provider’s platform.
SaaS is also independent of the deployment model. Most SaaS runs in the public cloud, but vendors may offer dedicated instances in a private cloud, and organizations combining SaaS with their own systems effectively operate a hybrid or multi-cloud estate.
Commercial and technical characteristics of SaaS
SaaS changes how software is bought and operated. Costs shift from capital expenditure to operating expenditure, and the contract, rather than an installation, defines service levels, data handling and exit conditions.
| Characteristic | Typical form | What to evaluate |
|---|---|---|
| Pricing | Per user per month, tiers or usage | Growth cost and minimum commitments |
| Service level agreement | Monthly availability target, often 99.9 percent or higher | Exclusions, credits and measurement method |
| Identity integration | Single sign-on via SAML or OpenID Connect | Availability on the chosen pricing tier |
| Data export | Bulk export, API or backup feature | Format, completeness and speed |
| Release cadence | Continuous or scheduled updates | Change notice and ability to test |
| Compliance evidence | Audit reports and certifications | Scope matches the services in use |
Integration happens mostly through APIs and webhooks. API rate limits, authentication methods and versioning policies therefore matter as much as the user interface, especially when the SaaS product becomes part of automated business processes.
Choosing SaaS or another model
SaaS is the right choice when the function is not a competitive differentiator and a standard product covers the requirements. When the software itself is the core of the business, or requirements are highly specific, building on PaaS or IaaS keeps more control.
| Situation | Recommended choice | Reason |
|---|---|---|
| Standard business function | SaaS | Fastest delivery, no operational burden |
| Strict data residency or air-gapped network | Self-hosted or single-tenant | Shared platforms may not meet constraints |
| Core product logic | PaaS or IaaS | Full control over code and roadmap |
| Deep customization required | Evaluate extensibility first | Heavy customization erodes SaaS benefits |
| Short-term project | SaaS on monthly terms | No setup cost, easy to stop |
Risks and common misconceptions
- Vendor lock-in: proprietary data models and workflows make migration expensive, so data portability belongs in the contract from the start.
- Assuming the provider backs up everything: many providers protect against their own failures, not against a customer deleting data, so independent backups may be needed.
- SaaS sprawl: departments subscribing without oversight create unmanaged accounts, duplicate costs and shadow IT.
- Overlooking offboarding: accounts of former employees often remain active unless provisioning is automated through the identity provider.
- Forced change: the provider controls the release schedule, so features can change or disappear without the customer’s consent.
A sound SaaS strategy keeps an inventory of subscriptions, enforces single sign-on and multi-factor authentication, reviews access regularly and documents an exit plan for every business-critical service.
The idea in brief
SaaS is like renting a fully furnished apartment instead of building a house. Someone else owns the building, fixes the plumbing and repaints the walls, and the tenant simply moves in and lives there for a monthly fee.
The tenant still decides who gets a key and what to keep inside. With SaaS, the provider runs the software, while the customer remains responsible for its users and its data.
A practical scenario
A growing engineering firm with 120 employees runs its own email server and an on-premises customer database maintained by one part-time administrator. Patching falls behind, and a hardware failure costs two days of email.
The firm moves email and documents to a SaaS office suite and its customer records to a SaaS CRM, connects both to a single identity provider with multi-factor authentication, and adds a third-party backup of mailbox data. The administrator now spends time on access reviews instead of server patching, email availability improves, and the firm budgets software as a predictable monthly cost.