<p>Craft uses a fairly typical <a href="https://en.wikipedia.org/wiki/Relational_model" rel="noreferrer">relational model</a>, where most<sup>1</sup> custom fields have a single column in the <code>content</code> table, set to an appropriate column type chosen by the field type. Unlike EAV, which crams all data into a fixed schema, Craft’s schema will change over time based on the custom fields you’ve configured.</p>
<p>There are both performance and storage benefits to this. However there’s one significant downside, which is that it’s possible to hit row size limits if you have hundreds of custom fields (particularly with MySQL). We’re going to address that in Craft 4 by splitting the <code>content</code> table up into multiple tables – one per field layout.</p>
<p><sup>1</sup>There are a couple exceptions: relational fields (like <a href="https://craftcms.com/docs/3.x/entries-fields.html" rel="noreferrer">Entries</a>) which store their data in the <code>relations</code> table, and fields that store nested elements such as <a href="https://craftcms.com/docs/3.x/matrix-fields.html" rel="noreferrer">Matrix</a> and a couple third party field types, which create their own field-specific <code>content</code>-esque tables.</p>

CC BY-SA 4.0
2020-11-12T18:19:02.617Z
Thank you! Is there a downside to breaking the content table into one table per field layout? Part of the cleverness of how Craft uses the content table is there aren't multiple database fields for one admin-defined Craft field. Were customer's running into what seems like a ludicrous field limit?
boogieknite
CC BY-SA 4.0
2020-11-12T22:03:34.543Z
No significant downside; most queries should look about the same, possibly with a couple additional JOINs, depending on the number of content types being queried at the same time. Yeah, people do hit it from time to time (there are some pretty intense content models running on Craft).
Brandon Kelly
CC BY-SA 4.0
2020-11-12T12:30:08.703Z
2020-11-12T12:30:08.703Z
Brandon Kelly
<p>I find Craft 3 to have a very clever database structure which eschews all of the issues I've seen with EAV.</p>
<p>Despite contrasting the differences between Craft 3's model and EAV, I'm having difficulty generating buy-in from the rest of my team who dismisses it as EAV. After so many times around the block, I wonder if it would help to point to a named database structure. I'm not looking for a comparison against EAV, rather a definition to provide my team.</p>
<p>Looked quite a bit and can't seem to pin down a name for Craft 3's database structure, is there one? If so, what?</p>
<p>Anecdote: one particularly snarky team member has taken to calling it &quot;The Junk Drawer&quot; after the content table. I sort of love it!</p>

<craft3><database>
Is there a name for Craft 3's database model?
# Is there a name for Craft 3's database model?

(Asked by: username_0 on 2020-11-11)

I find Craft 3 to have a very clever database structure which eschews all of the issues I've seen with EAV.

Despite contrasting the differences between Craft 3's model and EAV, I'm having difficulty generating buy-in from the rest of my team who dismisses it as EAV. After so many times around the block, I wonder if it would help to point to a named database structure. I'm not looking for a comparison against EAV, rather a definition to provide my team.

Looked quite a bit and can't seem to pin down a name for Craft 3's database structure, is there one? If so, what?

Anecdote: one particularly snarky team member has taken to calling it "The Junk Drawer" after the content table. I sort of love it!

**Tags:** craft3, database

---

## 1 answers

### Answer by username_1 on 2020-11-12. Score: 6 | Accepted answer

Craft uses a fairly typical [relational model](https://en.wikipedia.org/wiki/Relational_model), where most1 custom fields have a single column in the `content` table, set to an appropriate column type chosen by the field type. Unlike EAV, which crams all data into a fixed schema, Craft’s schema will change over time based on the custom fields you’ve configured.

There are both performance and storage benefits to this. However there’s one significant downside, which is that it’s possible to hit row size limits if you have hundreds of custom fields (particularly with MySQL). We’re going to address that in Craft 4 by splitting the `content` table up into multiple tables – one per field layout.

1There are a couple exceptions: relational fields (like [Entries](https://craftcms.com/docs/3.x/entries-fields.html)) which store their data in the `relations` table, and fields that store nested elements such as [Matrix](https://craftcms.com/docs/3.x/matrix-fields.html) and a couple third party field types, which create their own field-specific `content`-esque tables.

> **Comments:**
> **username_0**: Thank you! Is there a downside to breaking the content table into one table per field layout? Part of the cleverness of how Craft uses the content table is there aren't multiple database fields for one admin-defined Craft field. Were customer's running into what seems like a ludicrous field limit?  
> **username_1**: No significant downside; most queries should look about the same, possibly with a couple additional JOINs, depending on the number of content types being queried at the same time. Yeah, people do hit it from time to time (there are some pretty intense content models running on Craft).  

---

