Know What Each Extra Field in a Row Costs
Systems & Architecture · tables, performance, handoff
Updated 2026-08-04
- Ask what a new column costs before adding it to a list. A field that lives on a related record can turn one query into one query per row, the N+1 query problem, so fifty rows quietly become fifty-one database calls.
- Watch for the fields that are expensive by nature:
- An owner, author, or assignee name.
- A count of related items.
- A computed status that depends on other records.
- A permission check evaluated per row.
- Recognize the symptom in the interface: a list that is fast with ten rows and unusable with a hundred, where the slowdown scales with the number of columns rather than the amount of text.
- Make the expensive field optional rather than default. An off-by-default column keeps the common view fast and still serves the people who need it.
- Move the costly detail to the row's expanded state or its detail page. One record's worth of extra work is nothing, and a page's worth of it is the whole problem.
- Never add a column just to fill horizontal space. Every field in a list is paid for on every row, every render, for every user.
- Ask for the count separately from the list when both are expensive. An exact total across millions of rows can cost more than the page of results itself, and 1 to 20 of many is often enough.
- Bring the engineer into the column decision. The difference between a free field and an expensive one is invisible in the design file and obvious in the query.
A table is not a canvas, it is a multiplier, and every column you add is multiplied by every row you show.
Related guides
UX Handbook