More Than a Database

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 1 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Next: Look to the Mothership: The Standard Data Models

The question this module answers: What makes Salesforce different from a traditional database?

If you’ve been a Salesforce admin for a while, you already know how to create an object. Setup, Object Manager, New Custom Object. Give it a name, add a few fields, build a page layout, and ten minutes later users can work with it.

But what actually happened when you clicked Save?

If you come from a database background, you probably imagine Salesforce went off and created a new table. It didn’t. And understanding why is one of the places where you start moving from thinking like an admin or a developer to thinking like an architect.

Salesforce stores data, of course; there are databases underneath. But Salesforce isn’t a database with a nice screen on top. It’s a metadata-driven application platform, and that distinction shapes almost every decision in this course.

The Platform Has a Shape

In chapter 2 we built the model without worrying about Salesforce at all. That was on purpose: we listened for the nouns, built the conceptual model, added attributes, keys and relationships, and only then asked how Salesforce should implement it. Now we have to understand the thing we’re implementing it on.

I use a simple phrase for this: the platform has a shape. Salesforce gives us objects, fields, relationships, security, automation, APIs, transactions, reporting and search, and they’re all connected. When I create an object, I’m not just creating somewhere to put rows. I’m creating something that takes part in the security model, that automation can act on, that the APIs expose, that reports can use, that other objects can relate to, and that users, integrations and, more and more, agents will depend on. That’s a lot more than a table.

Metadata Is the Blueprint

Think about a building. There’s the building itself, and there’s the blueprint that describes it: where the walls are, where the doors go, how the rooms connect. Salesforce works the same way. An object definition is metadata. A field definition is metadata. A relationship is metadata. Most of what we configure in Setup is metadata, and the platform reads it at runtime to give our org its structure and behavior.

Salesforce describes the heart of the platform as both multitenant and metadata-driven: when we define an object or a field, the definition is stored as metadata, not as a new physical table or column for our org (Platform Multitenant Architecture (opens in a new tab)).

When I teach this, I pop the hood. Salesforce isn’t creating a new database for you each time you add an object. It’s adding a record to its own tables: a table of objects, a table of fields, a table of data, and pivot tables for indexes and relationships, all keyed by an org identifier that keeps your org’s data apart from everyone else’s. So adding a field is just adding an entry. That’s why you can create one on the fly, at lunchtime, in production.

It also explains something people trip over. When you write SELECT Id, Name, Special__c FROM Account, it looks like one table. Underneath, you’re reading the standard object and its custom field from different structures, so the platform is doing a join you never wrote. Indexes exist, but they don’t work the way a traditional database index does. You don’t need to know the internals for the exam. You do need to know that what you see in Object Manager isn’t a one-to-one picture of physical tables, and that the abstraction is both the platform’s power and the reason it behaves the way it does.

Click to enlarge

Look to the Mothership

One of the things I tell people in class is to look to the mothership. Before inventing some complicated way to do something on Salesforce, look at how Salesforce itself does it.

Take Account. You didn’t create it; Salesforce did. But you can add fields to it, automate around it, change its layouts, expose it through the APIs and relate other objects to it. Custom objects run on the same machinery, which is why standard and custom objects feel so similar when we build on them. In Apex, they even share a base class, the sObject.

That’s the habit this chapter builds on, and in the next module we look properly: at the standard data models Salesforce has already built for you.

We’re not building beside Salesforce. We’re extending it.

Your API Came With the Object

Create a table in a traditional database and you have a table. If another application needs to work with it, somebody has more work to do. Create an object on Salesforce, and the platform already understands it through its application and integration layers: it uses the same metadata to provide its REST and SOAP APIs, so the object’s records can be created, read, updated and deleted through them as soon as the object exists (Platform Multitenant Architecture (opens in a new tab)).

I didn’t design an API because I created an object. The platform knows the object, its fields, their types, its relationships and its security. That’s one reason Salesforce development moves so fast. It’s also why creating an object is a bigger decision than it looks: you’re plugging a structure into an entire application platform. And it cuts the other way too. People from SQL Server or Oracle sometimes ask me how to load data straight into the database. You can’t. Everything comes through the APIs.

The Apartment Building

Now the word you hear all the time: multitenancy. I think of it as an apartment building.

You have your apartment. Your furniture is yours, and your key shouldn’t open my door. But we share the building: the power, the water, the elevators, the lobby. Your org feels like your own environment, with your data, your objects, your automation. Underneath, Salesforce describes each org as a tenant, isolating each tenant’s data, metadata and logic while the infrastructure and services are shared (Platform Multitenant Architecture (opens in a new tab)). That’s how it can give every customer such a customizable platform without running a separate stack for each one.

But sharing the building has consequences. If one tenant buys a huge air conditioner and runs the hair dryer and the oven at the same time, they pop the circuit, and the whole floor goes dark.

You Can’t Take Over the Elevator

Stay in the building a minute longer. Imagine one resident announces, “I need the elevator from eight until noon. Nobody else can use it.” That doesn’t work in a shared building, and it doesn’t work on Salesforce either. One tenant can’t be allowed to consume shared resources without limit and degrade the platform for everyone else.

That’s where governor limits come from. If you’ve developed on Salesforce, you’ve probably met them as a list of numbers to memorize. I don’t want you to think of them that way. Salesforce applies limits at the transaction and org level so that one tenant’s workload doesn’t monopolize shared compute (Architecture Basics (opens in a new tab)). That’s the architecture; each individual limit is just the implementation of it. Later in the course we’ll care about particular limits because they change a design. For now, remember the building: you have enormous freedom to remodel your apartment. You don’t get to take over the elevator.

Salesforce IDs Are Part of the Abstraction

Every Salesforce record has an identity the platform understands, the record ID, and it works across every capability: the UI, the APIs, reports, automation.

In chapter 2 we said a good key is unique, unchanging, meaningless and never PII. The Salesforce ID fits that for Salesforce. But it isn’t the same thing as a business key. Your company may still have an ERP customer number, an employee number or a partner’s order number that means something across systems. Don’t confuse “Salesforce knows which record this is” with “the enterprise knows which business thing this is.” They’re different identity problems, and the second one comes back in integration and master data.

Objects Are More Than Storage

Here’s the shift I want you to make before the rest of this chapter. An object isn’t just somewhere to store data. A field isn’t just a column, and a relationship isn’t just a foreign key. I use the database comparisons when I teach, because they connect to what people already know. But if we stop there, we miss the architecture.

The object we choose decides which capabilities come with it. The field type affects validation, integration, search, reporting and how other systems read the data. The relationship decides lifecycle, ownership, sharing and deletion. Where we put the data affects storage, performance and scale. And because all of this runs on a shared platform, a choice that’s harmless with a hundred records can behave very differently with a hundred million. We’ll take those decisions one at a time.

Beyond the exam: what AI changes. For years, good names and descriptions helped the next admin or developer understand what we built. Now machines read that context too. An AI system working with a field called Flag2__c has the same problem a new developer does: what does this thing mean? Metadata isn’t decoration any more; it’s part of how machines understand the application.

What an Architect Decides Here

• Am I designing for the platform I’m actually on, or treating Salesforce like a generic database?
• Which parts of my design are business concepts, and which are Salesforce implementation choices?
• What platform behavior comes along with the structure I’m about to create?
• Which limits are expressions of the shared architecture, and which of them will shape this design?
• If this structure will be hard to change later, am I treating it as an architectural decision?

In chapter 2 we said: don’t design from Setup. Now you know another reason. Clicking New Custom Object doesn’t just give you a table; it connects another piece of your architecture to a metadata-driven, multitenant platform. But before deciding what object to create, there’s a more basic question: should this data live here at all? That’s next.

Explore

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), checked 2026-10-02, re-checked 2026-10-12: object and field definitions are stored as metadata, not new tables; shared tables (MT_Objects, MT_Fields, MT_Data, MT_Indexes) keyed by OrgID; the same metadata provides the REST and SOAP APIs.
• Salesforce Architects, Architecture Basics (opens in a new tab), checked 2026-10-02, re-checked 2026-10-12: governor and execution limits so code and transactions “don’t monopolize shared compute resources.”