SaaS
SaaS, or Software as a Service, is a cloud delivery model where software runs on the vendor's infrastructure and customers reach it through a web browser or API.
Definition
SaaS, or Software as a Service, is a cloud delivery model where software runs on the vendor's infrastructure and customers reach it through a web browser or API. There is nothing to install on local servers. The vendor handles hosting, security, scaling, and upgrades, and customers pay a recurring subscription instead of buying perpetual licenses.
Salesforce is the company most often credited with bringing SaaS to enterprise software. When it launched in 1999, business applications normally meant buying licenses, racking your own servers, and running upgrades yourself. Salesforce delivered customer relationship management entirely over the internet, and that choice shaped almost everything about how the platform behaves today.
How SaaS shapes the way Salesforce actually works
The promise behind "no software"
Salesforce built its early identity around the idea that enterprise software did not have to be painful. The Trailhead architecture material puts it plainly: Salesforce is a cloud company, and you never have to install new features or worry about your hardware. That single decision changes who carries the operational weight. In the old on-premise world, the customer bought the license, sized the servers, applied patches, and owned every outage. Under SaaS, those responsibilities move to the vendor. You log in, you work, and the machinery behind the login is somebody else's job. This is why a five-person startup and a global bank can both run Salesforce without either one staffing a data center for it. The cost model shifts too. Instead of a large upfront license purchase plus ongoing maintenance contracts, you pay a predictable per-user subscription. That turns software from a capital expense into an operating one, which is easier to budget and easier to scale up or down as headcount changes. The trade is control for convenience: you give up the ability to run a bespoke server stack, and in return you stop owning the plumbing.
Multitenancy is the engine underneath
SaaS at Salesforce scale only works because of multitenancy. Salesforce describes its architecture as a single shared multitenant database with a single schema that stores tenant-specific metadata and data, plus a multitenant kernel that reads that metadata at runtime to serve each customer their own apps, logic, and APIs. Trailhead uses an apartment building analogy: your company has its own space in the cloud, but you share the building with all kinds of neighbors, from mom-and-pop shops to multinational corporations. Your data stays isolated because everything is physically partitioned by OrgID using the database's own partitioning, so one tenant cannot see another tenant's records. The payoff is real for customers. No matter the size of your business, you get access to the same computing power, data storage, and core features as everyone else on the instance. A small nonprofit runs on the same hardened infrastructure as a Fortune 100 firm. Multitenancy is also why a single engineering team can improve the product for millions of users at once, rather than maintaining countless private installations.
Metadata makes one platform feel like yours
If every customer shares one database and one application runtime, how does each org look and behave so differently? The answer is metadata. Salesforce calls metadata "data about data," and it covers your objects, fields, page layouts, automation, and other customizations. The platform stores your configuration as metadata and reads it back at runtime to assemble your specific screens and behavior on the fly. Trailhead notes that the reason you can move so fast on the platform is that Salesforce knows how to store and serve that metadata immediately. This matters for SaaS because customization no longer requires changing source code or forking the product. When you add a custom field or build a Flow, you are not editing Salesforce's software. You are adding rows of metadata that the shared kernel interprets for your org alone. That separation is what lets thousands of tenants run wildly different applications on one codebase, and it is what makes upgrades safe. Because your customizations live in metadata rather than in modified code, a platform release can roll out without breaking your configuration.
Automatic upgrades three times a year
A defining feature of SaaS is that the vendor upgrades everyone, and Salesforce does this on a published calendar. New features arrive three times a year in seasonal releases named Spring, Summer, and Winter. The Salesforce Help upgrade guidance is direct: automatic upgrades are part of your contract, they happen on dates published up to a year in advance on the Trust site, and all customers run the same version with the latest features. Upgrades are designed to be quick and low-impact, scheduled during off-peak windows so subscribers feel almost nothing. Compare that to the on-premise past, where a major version upgrade could be a multi-month project with consultants, downtime, and regression testing. Here the heavy lifting happens once, centrally, for the whole instance. The flip side is that you cannot opt out or freeze on an old version forever. Because upgrades are mandatory, smart teams treat each release as a recurring event: they read the release notes, test new behavior in a sandbox, and plan around any change that touches their customizations. SaaS gives you continuous improvement, but it asks you to stay current.
Governor limits and the cost of sharing
Sharing infrastructure has a price, and on Salesforce that price shows up as governor limits. Because many tenants run code on the same servers, no single org can be allowed to monopolize CPU, memory, database time, or API calls. The runtime enforces hard caps on things like the number of records a single transaction can query, how many records it can update, and how many callouts it can make. To a developer arriving from a single-tenant world, these limits can feel strict. In a multitenant SaaS platform they are a feature, not a bug. They are what keep one badly written trigger from slowing down the neighbors who share your instance. The limits also push a particular style of building. You learn to bulkify code so it processes records in sets rather than one at a time, to query selectively, and to move heavy work to asynchronous jobs that get their own allowances. None of this would matter on a server you owned outright, because you could just throw more hardware at the problem. Under SaaS you do not own the server, so the platform sets the guardrails for you, and good Salesforce engineering means designing within them on purpose.
How SaaS, PaaS, and IaaS relate
SaaS is one layer in a stack of cloud service models, and Salesforce spans more than one of them. SaaS gives you finished applications you simply use, such as Sales Cloud or Service Cloud. Sitting underneath is Platform as a Service, where you build your own apps on the vendor's infrastructure without managing servers. Salesforce describes its platform as a modern Platform as a Service built for cloud computing, with multitenancy inherent in the design. Below that is Infrastructure as a Service, which provides raw compute and storage that you assemble yourself. The simplest way to keep them straight is by what you manage. With Infrastructure as a Service you still manage the operating system and the application. With Platform as a Service you manage only the application you build. With SaaS you manage almost nothing except your own data and configuration. Salesforce is interesting because a customer can consume it purely as SaaS by using its prebuilt clouds, or as a platform by building custom objects, Apex, and Lightning components on top. The same multitenant, metadata-driven foundation supports both, which is why understanding SaaS is the entry point to understanding everything else about the platform.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on SaaS.
- Platform Multitenant ArchitectureSalesforce
- Multitenancy and Metadata OverviewSalesforce
Hands-on resources to go deeper on SaaS.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the SaaS delivery model offer customers compared with on-premise software?
Q2. Which company is widely credited with mainstreaming SaaS for enterprise CRM?
Q3. Which burdens does the SaaS model lift off a customer's IT team?
Discussion
Loading discussion…