Designing Schemas That Scale
By the end of this lesson, you'll be able to:
- Identify schema design choices that avoid data skew and performance problems at scale
- Explain the risks of very large child record counts under one parent
Prerequisites: How Object Relationships Affect Sharing
Data skew
"Account data skew" happens when one Account owns an extremely large number of child records (tens of thousands) — updates to that Account, like an ownership change, can trigger expensive sharing recalculation across every child. "Ownership skew" happens when a single user owns hundreds of thousands of records — a similar recalculation cost when that user's role changes.
Designing around it up front
For high-volume child relationships, consider whether every child genuinely needs a lookup back to the same parent, whether Roll-Up Summary fields are necessary (they add recalculation cost too), and whether the org's role hierarchy depth and public groups are structured to minimize expensive sharing recalculation for the objects expected to grow largest.
Checking for concentrated child ownership
-- A concerning sign during schema review: how concentrated is child ownership?
SELECT AccountId, COUNT(Id)
FROM Contact
GROUP BY AccountId
ORDER BY COUNT(Id) DESC
LIMIT 5Running a query like this against real (or projected) data volumes during schema design surfaces potential data skew before it becomes a production performance problem.
Exercise
A new object, 'Sensor_Reading__c', will log a reading every minute from thousands of IoT devices, all related to a single 'Fleet__c' record via master-detail. What scale risk does this design create?
Show hint
Think about how many child records will eventually exist under one parent, and what master-detail's sharing behavior means for that.
Designing Schemas That Scale — Quick Check
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
A schema that works fine with test data can develop real performance and sharing-recalculation problems at scale — very large numbers of child records under one parent, or a single record owned by too many users, are both well-known scale risks worth designing around up front.