How many columns make a relation fat?

There is no universally accepted threshold; it is an informal relative description.

Is a wide table automatically denormalized?

No. Normalization is determined by dependencies and structure, not column count alone.

Should wide feature tables always be split?

No. Their suitability depends on feature meaning, storage, access patterns, and maintenance requirements.

AI Glossary / Data engineering and architecture / Intermediate

Fat Relation

Definition

Fat relation is an informal term for a relation with many attributes, often described more plainly as a wide table. It concerns the number of columns rather than the number of rows. There is no universal column count at which a relation becomes fat, and the label does not establish whether the design is normalized, efficient, or appropriate. This entry uses the term descriptively, not as a formal database category.

What it means

A table with 200 columns and 20 rows is wide, while a table with 5 columns and a million rows is tall. Either can contain a large amount of data, but they raise different design questions. A wide table might represent many legitimate properties of one entity, a deliberately flattened analytical dataset, or an accidental mixture of unrelated facts. Understanding what one row represents is more useful than judging the design from its width alone.

How it works

Width often grows as attributes are added, source tables are flattened, or repeated concepts are represented by additional columns. The resulting effects depend on column types, storage layout, selected fields, and workload. A row-oriented system may face different tradeoffs from a column-oriented analytical system. Database products also impose specific limits on columns and row representation. These are implementation constraints, not definitions of the informal term. Measure the actual queries and inspect dependencies before deciding whether to split the table.

Three practical examples

Feature preparation: an AI training dataset places hundreds of engineered features in one row per observation, requiring careful feature definitions and time boundaries.
Reporting: a flattened export combines customer, order, and product attributes for a specific analytical use, with a documented row grain.
Operational design review: a team investigates a customer table containing many unrelated optional fields to determine whether separate concepts have been mixed together.

Think of it this way

Think of a form that stretches across many pages because it asks many questions about one subject. Its length may be justified, or it may combine questions that belong on different forms. The analogy is limited because database width interacts with types, keys, dependencies, and storage engines. A short form can still be badly designed, and a long form can be well structured for its purpose.

Worked example

A toy Customer table has 40 customer attributes and columns Phone1, Phone2, and Phone3. The table's width alone does not identify the main issue. If customers may have any number of telephone contacts, the three fixed columns impose an artificial limit and make queries awkward. A CustomerPhone(CustomerID, PhoneID, Number, Type) relation can represent a variable number of contacts. Separately, suppose 100 analytical features each describe the same customer at a defined snapshot time. Keeping those features in one training table may be intentional. Splitting them merely to reduce the column count could add complexity without correcting a dependency problem. The two cases show why semantics and workload, rather than a simple width threshold, guide the decision.

Illustrative case study

Fictional example: Silver Birch Retail builds a wide export for a forecasting experiment. Review finds that some columns describe customers, some describe individual orders, and others were calculated after the prediction date. The team first defines one row as a customer at a particular cutoff time and removes or recomputes incompatible fields. It then measures whether the chosen storage supports the required feature selection. This invented case illustrates grain and leakage review, not a claim that wide analytical tables are inherently unsuitable for AI.

Common misconceptions and mistakes

Do not equate fat relation with a large number of rows or with every wide-column database product. Do not assume a wide table necessarily violates normal forms, because normalization depends on relationships among attributes and keys. Avoid concluding that every query reads every column in every storage engine. Also distinguish many columns from large values: a narrow table containing a large document can have substantial storage needs. The informal label should start a discussion, not replace a diagnosis.

Business use

When reviewing a wide design, document row grain, keys, functional dependencies, optional fields, and the queries that matter. Identify groups with independent lifecycles or access requirements. For analytics, track each feature's definition, source, and availability time. Select only needed fields where appropriate and test performance using representative data. Before approaching a product limit, consult the specific version's documentation and consider the consequences of schema evolution. Any redesign should preserve meaning and be validated against actual use cases.

Check your understanding

Table A has 8 columns and 50 million rows; Table B has 300 columns and 100 rows. Which is wider?

Answer: Table B has more attributes and is wider. That comparison alone does not establish which occupies more storage, runs more slowly, or has a better logical design.

Related terms

Normalization
Functional dependency
wide table
relation degree
table cardinality
row grain
denormalization
feature table
column-oriented storage
schema evolution

Learn next

inventory a wide table and group columns by meaning and lifecycle. Identify the key and the intended row grain. Compare one representative query before and after a justified redesign, while checking that results and business rules remain correct rather than focusing only on column count.

Sources

Sources: PostgreSQL 16, PostgreSQL Limits, https://www.postgresql.org/docs/16/limits.html ; Cornell Virtual Workshop, First Normal Form, https://cvw.cac.cornell.edu/RelationalDBs/design-create/first_normal_form . Primary documentation and institutional teaching excerpts consulted for implementation limits and repeating-data design considerations. These sources support the surrounding database concepts, not a standardized definition of “fat relation.” Montana State University, Functional Dependencies, https://www.cs.montana.edu/courses/spring2004/435/lectures/FD.html , uses the informal label for grouping many attributes. No universal width threshold is asserted.

Previous: Fast probability integration Next: Fault tolerance