<p>In Craft, <strong>all</strong> fields are stored in the <code>craft_content</code> table. They are otherwise independent of any field groups, layouts, sections, or anything else.</p>

<p><strong>PRO:</strong> This means that any element (Entry, Category, Asset, etc) can access any field.</p>

<p><strong>CON:</strong> This means that every element carries the weight of every field. Though if those fields are all empty, the performance impact is almost non-existent.</p>

<p>There's historically been some minor debates over whether or not this tradeoff is worth it... But I think it's safe to say that the benefits vastly outweigh any negligible performance issues. The simple fact is, having all fields in the same table is rarely (never?) the true bottleneck.</p>

CC BY-SA 3.0
2016-03-21T20:48:13.103Z
2016-03-21T20:48:13.103Z
Lindsey D
<p>I'm a HUGE fan of Craft, but I'm wondering how specifically it's able to reuse fields in different sections. I'm very accustomed to an ExpressionEngine environment, where each field's shortname has to be unique. How did P&amp;T build Craft so this is possible?</p>

<field><custom-field>
How is Craft able to reuse fields in different Sections? (As opposed to EE.)
# How is Craft able to reuse fields in different Sections? (As opposed to EE.)

(Asked by: username_0 on 2016-03-21)

I'm a HUGE fan of Craft, but I'm wondering how specifically it's able to reuse fields in different sections. I'm very accustomed to an ExpressionEngine environment, where each field's shortname has to be unique. How did P&T build Craft so this is possible?

**Tags:** field, custom-field

---

## 1 answers

### Answer by username_1 on 2016-03-21. Score: 6 | Accepted answer

In Craft, **all** fields are stored in the `craft_content` table. They are otherwise independent of any field groups, layouts, sections, or anything else.

**PRO:** This means that any element (Entry, Category, Asset, etc) can access any field.

**CON:** This means that every element carries the weight of every field. Though if those fields are all empty, the performance impact is almost non-existent.

There's historically been some minor debates over whether or not this tradeoff is worth it... But I think it's safe to say that the benefits vastly outweigh any negligible performance issues. The simple fact is, having all fields in the same table is rarely (never?) the true bottleneck.


---

