Database Table
A database table in Salesforce is the storage representation of an object.
Definition
A database table in Salesforce is the storage representation of an object. Every standard object (Account, Contact, Opportunity, Case, and so on) and every custom object you create maps to a row in Salesforce's metadata catalog, which the runtime then translates to space inside the platform's shared relational storage. Fields are columns, records are rows, and the table inherits the platform's tenant isolation, sharing, and field-level security automatically.
You never write CREATE TABLE or DROP TABLE directly in Salesforce. The Object Manager, the Metadata API, and Lightning Schema Builder are the legitimate ways to define a Salesforce database table. Behind the scenes the platform does not allocate one dedicated physical table per object. It stores most records in a small set of shared, typed-column tables with a metadata layer that maps your specific object and field names onto pre-allocated column slots.
How a database table fits the Salesforce schema model
Standard, custom, external, and big object tables
Salesforce exposes four classes of database tables in your metadata. Standard objects ship with the platform and cannot be dropped. Custom objects are anything you define with the __c suffix, governed by the same storage rules as standard objects. External objects use the __x suffix and are surfaced through Salesforce Connect; the rows actually live in an outside system. Big Objects use __b and are designed for billion-row archival workloads with relaxed query semantics. Knowing which class you need before you build saves you a rebuild later.
Columns: standard, custom, and system fields
Every database table comes with a fixed set of system fields: Id, CreatedById, CreatedDate, LastModifiedById, LastModifiedDate, SystemModstamp, IsDeleted, and OwnerId on most objects. Standard objects add their own typed columns (Account.Industry, Opportunity.StageName). Custom fields you add show up with the __c suffix (Account.Region__c). Each field type has a fixed storage representation behind the metadata, which is why a Text(255) and a Picklist behave differently when you query large volumes.
Relationships: lookup, master-detail, and external IDs
Tables link to each other through relationship fields. A lookup field is a soft foreign key: you can delete the parent and the child survives with a null reference. A master-detail field is hard: deleting the parent cascades to the children, and ownership and sharing flow from parent to child. Hierarchical relationships (only on User) and many-to-many junctions (a custom object with two master-details) extend that model. External Id fields let you reference a row in an upsert without knowing the Salesforce Id ahead of time.
Indexes on a Salesforce database table
Each table inherits a set of automatic indexes: Id, Name where applicable, OwnerId, CreatedDate, SystemModstamp, all lookup and master-detail fields, and any field flagged Unique or External Id. Other fields need a custom index, which Salesforce Support adds on request when a query pattern justifies it. Without a usable index, a SOQL query against millions of rows will scan the whole table, and that is what produces the slow-query and timeout errors people associate with poorly designed reports.
Record storage and per-row billing
Every standard and custom object stores 2 KB per record for billing purposes, regardless of how full the row is. Person Accounts and a few specialized objects bill 4 KB. There is no hard row count limit on most objects, but the data storage allocation for your tenant caps total volume across all tables. Hit it, and inserts fail with STORAGE_LIMIT_EXCEEDED until you free space or buy more allocation.
Triggers, sharing, and field-level security sit outside the table
In a traditional database you might write triggers in SQL and grant SELECT to roles. In Salesforce those concerns are decoupled from the storage. Triggers are Apex code attached to insert, update, and delete events. Sharing is configured per object through the org-wide default, roles, sharing rules, and manual shares. Field-level security and CRUD permissions live on profiles and permission sets. The platform composes these layers on every query rather than baking them into the table definition.
Inspecting a database table''s structure
To see the schema for any Salesforce object, you have several entry points. Object Manager (Setup, then Object Manager, then pick the object) is the admin view. The Salesforce Inspector browser extension surfaces describes from any record page. The REST describe call (/services/data/vXX.X/sobjects/Account/describe) returns the full field metadata as JSON. Schema Builder draws a visual graph including relationships. For developers, the Tooling API exposes describe information programmatically.
How to create a custom object (Salesforce's equivalent of CREATE TABLE)
You never run CREATE TABLE in Salesforce. You define a custom object through the Object Manager and the platform provisions storage, indexes, and the metadata mapping for you. The wizard takes about a minute; the choices you make in it are mostly permanent.
- Open Object Manager
Setup, then Object Manager, then Create, then Custom Object. The wizard handles the basic configuration and you can refine the rest after the object exists.
- Set the label and API name
Singular and plural labels appear in UI strings throughout the platform. The Object API Name auto-derives from the singular label and ends with __c. It is what your code, formulas, and integrations reference. The API name is permanent once you save.
- Choose the Name field type
Pick Text for most cases or Auto Number when records should get a sequential identifier. Text Name fields are searchable from the global search; Auto Number fields are not, though you can add a separate searchable field if you need both.
- Configure platform features
Allow Reports, Allow Activities, Track Field History, In Chatter Groups, and Help Settings. Allow Reports and Track Field History are the two most commonly missed. Leaving them off costs you analytics and audit later, and Allow Reports cannot be toggled on after deployment without rebuilding the object.
- Set the deployment status
Deployed makes the object available immediately. In Development hides it until you flip the switch, which is useful when you want to define fields and load test data before exposing anything to users.
- Add fields, page layouts, and tabs
After the object exists, use Fields and Relationships to add columns and Page Layouts to control how they render. Add a custom tab if users need to navigate directly to a list view of the records.
- The API Name (__c suffix) is permanent. Renaming the label is fine, but the API Name reflects the original creation, which is why you sometimes see API names that no longer match what users call the object.
- Allow Reports cannot be toggled on after deployment without recreating the object. Always turn it on at creation, even if you do not plan to build reports immediately.
- Big Object tables do not support standard triggers, validation rules, formulas, or workflow. Choose the type with the storage horizon in mind, not the convenience.
- Each custom object counts against your Custom Objects per Edition limit. Setup, then System Overview, shows current usage.
Trust & references
Straight from the source - Salesforce's reference material on Database Table.
- Create a Custom ObjectSalesforce Help
- Standard Objects ReferenceSalesforce Developers
- Schema BuilderSalesforce Help
Hands-on resources to go deeper on Database Table.
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 a Salesforce object correspond to a database table?
Q2. Do Salesforce developers usually access the database directly?
Q3. Why think about objects as tables?
Discussion
Loading discussion…