Database
In Salesforce, the database is the persistent relational storage layer that holds every record in your org.
Definition
In Salesforce, the database is the persistent relational storage layer that holds every record in your org. Standard objects (Account, Contact, Opportunity), custom objects, metadata, and platform-level configuration all live as rows in tables on a shared multi-tenant infrastructure. You never touch the underlying database directly. Salesforce sits between you and the storage, exposing the data through SOQL queries, SOSL searches, the REST and SOAP APIs, and the user interface.
The platform runs on a multi-tenant architecture where every customer shares the same physical database but sees only their own data. Each row carries an organization identifier that Salesforce uses to enforce tenant isolation at the query layer. That design is why you can deploy a custom field in seconds (it adds a column to a shared, pre-allocated table rather than altering a customer-specific schema), and why governor limits exist to keep one tenant's heavy query from starving the others.
What the Salesforce database actually looks like under the hood
Multi-tenant architecture and tenant isolation
Salesforce runs on a shared set of application servers and a shared set of database servers, with every org partitioned by a hidden OrgID column on every table. Every query the platform issues has that OrgID baked into the WHERE clause before it ever reaches the underlying Oracle layer. You cannot see another tenant's data even if you tried, because the platform rewrites your SOQL to enforce isolation. Sharing rules, profiles, and permission sets then apply on top of that scope, narrowing visibility inside your own tenant.
Standard objects, custom objects, and the underlying storage tables
Both standard and custom objects map to the same set of generic relational tables behind the scenes, not to one physical table per object. Salesforce stores records in shared data tables with a fixed number of typed columns and a metadata mapping layer on top. When you add a custom field, the platform attaches a label, type, and validation to one of those pre-allocated columns. It does not run ALTER TABLE on the underlying schema. That is why custom fields appear instantly instead of requiring a maintenance window, and why deploying a new object across thousands of orgs takes seconds rather than hours.
The metadata-driven runtime
Almost everything in Salesforce is metadata rather than code. Page layouts, validation rules, workflow steps, field labels, picklist values, and even your custom objects themselves are records in a metadata table. The runtime reads that metadata on every request to decide how to render a page, validate input, or apply security. This is what lets two customers run very different applications on the same physical infrastructure, and it is also why your sandbox changes can be deployed as metadata XML rather than database scripts.
Data Storage versus File Storage
Salesforce bills storage in two distinct buckets. Data Storage covers structured records: most objects bill 2 KB per record regardless of actual field content, and a few (like Person Accounts) bill 4 KB. File Storage covers attachments, Files (ContentDocument), and images. The split matters at scale. A million Tasks consumes about 2 GB of data storage, while a single 100 MB video sits entirely in file storage. Knowing which bucket grows fastest in your org helps you forecast license costs before you hit the limit.
Indexes and the Query Optimizer
A short list of fields are indexed automatically: Id, Name, RecordTypeId, OwnerId, all lookup and master-detail fields, and any field marked Unique or External Id. Other fields need a custom index, which Salesforce Support creates on request when a query pattern justifies it. The Salesforce Query Optimizer decides whether a SOQL or report query will use those indexes by checking selectivity. If a filter targets less than 10 percent of the table (or 30 percent for standard indexes), the optimizer picks the index. Above that threshold it scans the whole table, which is why selective filtering matters on objects with millions of rows.
Big Objects and External Objects as alternatives
Some data does not belong in standard records. Big Objects hold up to a billion rows for long-term archival, with their own query syntax (Async SOQL) and no triggers or sharing rules. External Objects use Salesforce Connect to surface data from outside systems (SQL Server, Oracle, REST endpoints) as if it were native, without ever copying the rows in. Both extend the platform's storage model when you would otherwise blow past data storage limits or duplicate a source-of-truth system.
Field history, audit trail, and backup
The database tracks change history at the field level. Field History, configured per object, retains the last 20 fields you choose to track, with rows moving into the FieldHistoryArchive object after 18 months. Field Audit Trail (a paid add-on) extends retention to 10 years and lets you track 60 fields per object. The platform also supports a scheduled weekly Data Export (CSV per object), and the Backup and Restore add-on takes daily snapshots you can restore selectively. None of these is a substitute for a real third-party backup tool when compliance requires point-in-time recovery.
How to monitor and manage your Salesforce database storage
You cannot tune the underlying database engine, but you can see exactly how your org consumes storage and which objects are the heaviest contributors. The Storage Usage page is your starting point, and a few habits keep you well below the limit.
- Open Storage Usage from Setup
In Setup, type Storage Usage in the Quick Find box and open the page. The top section shows Data Storage and File Storage totals against your allocation, followed by a per-object breakdown of record counts and bytes used.
- Identify the heaviest objects
Sort by Storage descending. Tasks, EmailMessage, FeedItem, and custom logging objects are the usual top consumers. A row count in the millions on a 2 KB-per-record object adds up to tens of gigabytes fast.
- Archive or delete high-volume records
Use Apex Schedulable jobs, Big Objects, or third-party tools to move old records out of standard storage. Closed Tasks older than three years and old EmailMessage rows are common archival candidates.
- Audit Field History settings
Field History is opt-in per field. Untrack fields you no longer audit, and consider Field Audit Trail if compliance requires longer retention than 18 months.
- Schedule a weekly Data Export as your safety net
Setup, then Data Export, then schedule weekly. This is a free, self-serve backup that lets you recover from accidental mass deletes outside the 15-day Recycle Bin window.
Enterprise Edition gets 10 GB plus 20 MB per user license. Professional gets 5 GB plus the same per-user add-on. Most other editions follow a similar floor-plus-per-user pattern.
Most editions get 10 GB plus 2 GB per user license. Orgs with heavy attachment or image workloads need to monitor this separately from data storage.
Sold separately, typically in blocks of 100 million to 1 billion rows. Use it for archived activity history or telemetry that does not need real-time edits.
Standard retention is 18 months. Field Audit Trail (paid add-on) extends this to 10 years and lets you keep 60 fields per object.
- Recycle Bin records still count toward your data storage allocation until they are permanently deleted or 15 days have passed.
- Reports and dashboards do not consume data storage. Their definitions live as metadata, not as records.
- Attachments uploaded before Files were introduced are stored as Attachment records and count toward data storage, not file storage. Migrating them to ContentVersion frees data storage but does not reduce overall storage spend.
- External Object rows do not count toward your data storage because they live in the source system. The platform just renders them through the OData connection.
Trust & references
Straight from the source - Salesforce's reference material on Database.
- Storage Allocations by EditionSalesforce Help
- Monitor Storage UsageSalesforce Help
- Multi-Tenant Architecture and the Lightning Platform DatabaseSalesforce Developers
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. How does Salesforce's database architecture work?
Q2. How do Salesforce objects map to database concepts?
Q3. Why do Salesforce governor limits exist?
Discussion
Loading discussion…