LDV strategy

LDV strategy

Most Salesforce advice assumes modest data volumes. At the architect level you must plan for the opposite: objects holding millions or tens of millions of records, where designs that felt fine in a demo cause query timeouts, slow list views, and locking. This is the domain of large data volume (LDV) strategy, and it is one of the most heavily weighted architect topics because the failure modes are severe and expensive to unwind.

The root cause of most LDV pain is the full table scan: a query whose filters are not selective, forcing the database to examine every row. Salesforce considers a filter selective when it targets an indexed field and returns a small enough fraction of the object (roughly under 10% for standard indexes, with an absolute cap). Standard indexes exist on the record Id, Name, owner, lookups, and audit fields; other fields need a custom index (requested via Salesforce support or created automatically for External Id and Unique fields).

Several forces make queries non-selective and must be designed around. Data skew — thousands of child records under one parent (ownership skew, lookup skew, or account data skew) — causes record-locking contention and slow sharing recalculation. The fix is to spread ownership (for example, an "integration bucket" of many users rather than one) and to avoid single mega-parents.

Selective query checklist:
  [ ] Filter on an indexed field (Id, Name, ExternalId, Unique, or custom index)
  [ ] Filter returns < ~10% of rows (and under the row threshold)
  [ ] Avoid negative operators (!=, NOT, LIKE '%x') — they defeat indexes
  [ ] Avoid formula fields and low-cardinality picklists as the sole filter
  [ ] Watch for OR across un-indexed fields

Design deliberately: choose selective filters, request custom indexes for high-cardinality fields you query often, mitigate skew, and consider Big Objects for truly massive, append-only datasets that only need occasional access. The next lessons go deeper into two of the most powerful LDV tools — skinny tables and indexing, then archiving. Treat data volume as a first-class design input from day one, because retrofitting selectivity into a large, live object is painful.