📖 Read · 20 XP
One server, thousands of tenants (why governor limits exist)
One server, thousands of tenants
When you build on AWS, you get your own slice of compute. Salesforce works differently. Your company's org runs on the same servers and the same database as thousands of other companies. That's multi-tenancy.
Every org's data sits in shared tables, separated by an org ID. Your custom objects and fields aren't real database columns. They're metadata that the platform reads at runtime to work out what your data looks like.
That's how Salesforce can upgrade everyone three times a year without breaking anybody: the platform owns the runtime, and you own the configuration and code that run on it.
The catch: governor limits
If you share a server with thousands of strangers, someone's infinite loop can't be allowed to slow everyone else down. So Salesforce counts what every transaction does and stops it hard when it goes too far:
| Limit (per synchronous transaction) | Max |
|---|---|
| SOQL queries | 100 |
| Records retrieved by SOQL | 50,000 |
| DML statements | 150 |
| Records processed by DML | 10,000 |
| CPU time | 10,000 ms |
| Heap size | 6 MB |
Go over a limit and the platform throws a System.LimitException. You can't catch it, and everything in the transaction is rolled back.
🦝 Quill's whole personality comes from this table. He has seen things.
What this means for you as a developer
- Code has to be bulk-safe: a trigger might get 1 record or 200 at once.
- Queries and DML belong outside loops.
- Every Run in Apex Quest shows your limit usage. Start noticing those bars now.