PaaS
A PaaS (Platform as a Service) is a cloud computing model where a vendor hosts the hardware, operating systems, runtime, and development tools, and customers build and run their own applications on top of it.
Definition
A PaaS (Platform as a Service) is a cloud computing model where a vendor hosts the hardware, operating systems, runtime, and development tools, and customers build and run their own applications on top of it. The customer writes the app and owns the data. The vendor handles servers, patching, scaling, and uptime.
In Salesforce, the PaaS offering is the Lightning Platform, which debuted in 2008 as Force.com and is now folded into the broader Agentforce 360 Platform. It lets admins and developers create custom objects, fields, logic, and user interfaces that run in Salesforce's multitenant cloud. You never provision a database or rack a server. You define what the app should do, and the platform runs it.
How Salesforce delivers PaaS
Where PaaS sits between IaaS and SaaS
Cloud computing is usually split into three service models, and PaaS is the middle one. With IaaS (Infrastructure as a Service), the vendor rents you raw compute, storage, and networking, and you still install and patch the operating system, runtime, and everything above it. With SaaS (Software as a Service), you get a finished application like Sales Cloud and just configure it. PaaS sits in between. The vendor manages the servers, OS, and runtime, while you build the application logic and data model on top. The practical effect is a shift in what you spend time on. On IaaS you think about machines. On SaaS you think about settings. On PaaS you think about the app itself, its objects, its automation, and its screens. Salesforce blurs the line a little because the same org can run pre-built SaaS clouds and your own PaaS-style custom apps side by side, sharing one data model and one security layer. That overlap is part of why teams adopt the platform: the CRM and the custom app are not two separate systems.
The multitenant, metadata-driven core
The thing that makes Salesforce PaaS work is its architecture, which Salesforce describes as multitenant and metadata-driven. Multitenant means many customers (tenants) share the same infrastructure and the same application runtime at once, the way many companies share one apartment building while keeping private units. There is a single shared database with a single schema that stores each tenant's metadata and data, kept logically separate so one org never sees another's records. Metadata-driven is the second half. Your customizations, the objects you create, the fields you add, the validation rules and flows you build, are stored as metadata, which is data that describes your app rather than business records. A multitenant kernel, the application runtime, reads that metadata at request time and generates your specific app on the fly. You are not deploying compiled software to a server you own. You are adding metadata that the shared engine interprets. This is why a change in Setup takes effect immediately and why the same platform release reaches every customer at once.
Governor limits are the price of sharing
Because tenants share one runtime, no single org can be allowed to hog the machine. If one customer's code ran an infinite loop or queried millions of rows on every transaction, every other tenant on that instance would slow down. Salesforce solves this with governor limits, an extensive set of governors and resource limits attached to platform code execution that the runtime enforces strictly. These limits cap things like the number of SOQL queries per transaction, rows returned, CPU time, heap size, and DML statements. Hit one and the transaction fails with a clear error rather than degrading the shared system. Developers coming from a single-tenant world sometimes find this restrictive at first. The trade is deliberate. You give up unbounded resource use, and in return you get a platform that stays fast and available without you tuning a database or sizing a server. Writing bulk-safe code that processes records in batches, rather than one row at a time, is the main skill the limits push you toward.
What you actually build on the platform
On the Salesforce PaaS you build with a spectrum of tools, from fully declarative to fully programmatic. On the low-code end, point-and-click features let almost anyone create a custom object, add fields, design a record page in Lightning App Builder, and automate work with Flow. None of that requires writing code, and it covers a large share of real business requirements. On the pro-code end, you write Apex, Salesforce's server-side language, for complex logic and triggers, and Lightning Web Components for custom interfaces. APIs (REST, SOAP, Bulk, and more) let outside systems read and write your data and call your logic. For apps that need elastic scale or open-source runtimes outside the core, Heroku extends the platform. The point is that the same data, the same user, and the same sharing model back all of it. A flow built by an admin and an Apex class written by a developer operate on the same records under the same permissions, which keeps a custom app coherent instead of bolted on.
From Force.com to the Agentforce 360 Platform
Salesforce introduced its PaaS as Force.com at Dreamforce in 2008, positioning it as the database, code, and UI layer on which all the apps are built, separate from the salesforce.com CRM functionality that ran on top. Over the years Salesforce rebranded the offering, first as the Lightning Platform, and the platform brand now sits inside the Agentforce 360 Platform. The name changes track real architectural shifts, not just marketing. Salesforce moved from a more monolithic design toward independent services, adopted Hyperforce to run the platform on public cloud infrastructure, added Data 360 and lakehouse data stores alongside the relational database, and wove in generative AI and agentic capabilities. For a working admin or developer, the through line matters more than the labels. The metadata-driven, multitenant model that made Force.com productive in 2008 is still the model you build on today. Understanding that history explains why so much Salesforce documentation, URL, and API still carries the Force.com name.
Why teams choose a PaaS instead of building from scratch
The case for PaaS is mostly about where your effort goes. A team that builds a custom app on bare infrastructure spends real time on servers, databases, authentication, backups, scaling, and security patches before writing a line of business logic. On Salesforce PaaS, those concerns are handled by the vendor, so a small team can ship an internal app in weeks instead of months. There is a real cost to weigh against that speed. You build within the platform's model and limits, so an app that needs an exotic database, an unusual runtime, or millisecond latency at massive scale may fit poorly. You also accept platform pricing and a degree of vendor lock-in, since the app is expressed in Salesforce metadata and Apex. For the common case, a business app that manages records, enforces process, and connects to a CRM, the productivity usually wins. The skill is knowing when a requirement sits comfortably inside the platform and when it belongs on Heroku or an external system instead.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on PaaS.
Hands-on resources to go deeper on PaaS.
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. Which Salesforce offering is the canonical PaaS in the Salesforce context?
Q2. Where does PaaS sit relative to IaaS and SaaS in the cloud service stack?
Q3. What infrastructure responsibility does a developer give up by building on Salesforce as a PaaS?
Discussion
Loading discussion…