--- title: "Skinny tables: what they are and how to get one" url: "https://trailassembly.com/skinny-tables/" topic: "Architecture" published: "2026-09-17T03:43:35+00:00" updated: "2026-10-06T13:56:56+00:00" --- # Skinny tables: what they are and how to get one **The short answer:** a [skinny table](https://trailassembly.com/selective-queries-at-scale/) is a copy of the fields you query most, stored without the joins the standard structure requires, built and maintained by Salesforce at your request. It makes big reports and list views faster. You cannot create one, you cannot see one, and a fair number of routine schema changes silently invalidate it. ## Why they exist Standard and custom fields for an object are not stored in one place. The platform keeps them across separate structures, and a query touching both standard and custom fields has to join them. On an object with millions of rows and a report pulling thirty columns, that join is the cost. A skinny table flattens the fields you actually use into one structure. No join. The optimiser uses it automatically when the query only touches fields the skinny table contains. Your SOQL does not change, your report does not change, and nothing in the UI tells you it happened. ## How to get one Open a case with Salesforce Support. They are enabled for customers who need them, typically on objects with large data volumes where a specific report or [list view](https://trailassembly.com/salesforce-list-views-and-filters/) is timing out. Bring the same evidence you would bring for an index request: - The object and its row count. - The exact report, list view or SOQL that is slow, with its execution time. - The full list of fields that query touches, including filter and sort fields. - Evidence that indexing alone has not solved it. Support decides whether the case qualifies. They will not build one because a query on 40,000 rows feels sluggish. The threshold is real data volume. ## What a skinny table can contain There is a hard cap of 100 fields per skinny table, and the field types allowed are limited: - Checkbox - Date - Date and time - Email - Number - Percent - Phone - Picklist (single select) - Text - Text area - URL Long text area, rich text, multi-select picklist and formula fields are not included. That last one matters: if your slow report leans on formula fields, a skinny table will not help it, because the query still has to touch fields outside the skinny table and the optimiser falls back to the normal path. Skinny tables also exclude deleted records, so they do not cover queries using `ALL ROWS` or the recycle bin. ## The all-or-nothing rule This is the part that catches teams out. A skinny table is used only when every field the query references is in it. One extra column added to the report, one new filter field, and the optimiser stops using the skinny table entirely. Performance reverts to what it was before, with no warning and no error. The practical consequence: when a report that was fast suddenly is not, ask what changed in the report before you go looking at data volume. ## What invalidates one Several ordinary admin actions require Support to rebuild the skinny table: - **Changing a field’s type** that is in the skinny table. - **Deleting a field** that is in it. - **Adding a field** you now need in the query, which means a new request rather than a rebuild. - **Sandbox copies.** Skinny tables do not automatically carry to a refreshed sandbox. Ask Support to replicate them. - **Some org migrations and object changes**, where Support will normally recreate them as part of the work. Nothing tells you the table is gone. The report just gets slow again. If you have skinny tables, write down which objects and which fields somewhere your team reads, because the knowledge otherwise leaves with whoever filed the case. ## Are they worth pursuing Only after the cheaper options. Reduce the column count in the report. Add a selective filter so fewer rows are scanned. Get a custom index on the filter field. Archive rows you no longer need in the object. Each of those is faster to try and under your own control. Skinny tables earn their place on a stable, high-volume object where a business-critical report has a fixed shape that nobody changes. The stability is the requirement. On an object whose reports change monthly, the table will be invalidated faster than Support can rebuild it. ## Frequently asked **Can I query a skinny table directly?** No. It is invisible to SOQL, the [Metadata API](https://trailassembly.com/apex-metadata-api-from-apex/) and the UI. You write normal queries and the optimiser decides. **Do they keep up with data changes?** Yes, they are maintained in sync with the source records by the platform. There is no refresh to schedule. **Do skinny tables help Apex queries?** They can, under the same all-fields-present rule. Most of the benefit reported in practice is on reports and list views, because those are where the wide field lists live. **Is there a cost?** No licence charge. The cost is the operational dependency on Support for every subsequent change. --- Source: https://trailassembly.com/skinny-tables/ Trail Assembly — independent Salesforce write-ups.