ddtcorex

06 Jul 2026 · 2 min read

Magento 2 EAV & database: table prefix and schema

Magento's EAV model lets products carry arbitrary attributes without schema changes. We cover table prefixes and how they keep multi-tenant installs safe.

Magento 2's data model is the part most likely to surprise newcomers. Products don't live in a single products table — they're spread across an EAV (Entity-Attribute-Value) structure. This post explains why, and how the database is organized around it.

What EAV solves

In a typical store, every product has different attributes: a T-shirt has size and color; a laptop has RAM and CPU. A fixed products table would force a column for every possible attribute — most of them NULL.

EAV instead stores attributes as rows:

  • eav_attribute — the catalog of possible attributes.
  • catalog_product_entity — the product entities.
  • catalog_product_entity_varchar / _int / _text / _datetime — values, typed by backend type.

Add a new attribute and Magento writes a row in eav_attribute — no ALTER TABLE. That flexibility is exactly why Magento handles enormous, heterogeneous catalogs.

The cost (and the fix)

EAV means a product's full record is assembled from many joined tables, which is slower for reads. Magento answers this with flat index tables (e.g., catalog_product_flat) and the indexer pipeline (bin/magento indexer:reindex) that materializes denormalized reads. Search itself is offloaded to OpenSearch (covered later).

Table prefixes for safe co-location

In shared or multi-tenant databases, a table prefix namespaces every Magento table (mage_ by convention). This lets multiple Magento installs share one database, and it keeps Magento's tables distinct from your custom ones.

Govard propagates the configured table prefix into the generated env.php so the application, installers, and any modules all agree on the prefix — a common source of "table not found" errors when done by hand.

Practical tips

  • Don't query EAV directly in custom code; use the repository/collection APIs.
  • Keep the indexers on schedule (or use the message queue) so flat tables stay fresh.
  • Prefix once, at install; changing it later is painful.

What's next in this series

This data model underpins Magento's multi-store and B2B capabilities. Next: scopes, websites, and B2B basics.

Next in this series: Multi-store, scopes & B2B basics — /blog/magento2-multistore-b2b

magento2eavdatabase