The EAV model (Entity-Attribute-Value, German: Entity-Attribute-Value) is a database design pattern in which the properties of an object are not stored as fixed columns in a table, but as individual records comprising three components: the entity (the object), the attribute (the property) and the value. In e-commerce, EAV is best known as Magento’s product data model — and this is precisely where it becomes the key challenge when migrating to a different shop system.
How the EAV model works
In a traditional relational table, a product has fixed columns: one column for the name, one for the price, one for the weight. Every new property means a new column. This is quick and clear, but inflexible: If you need twenty special attributes for a single product group, you end up bloating the table for all other products as well.
The EAV model turns this principle on its head. Instead of wide tables with many columns, there are narrow tables with few columns and many rows. Put simply, a value row looks like this: ‘Entity 1234 (the product) has the value “blue” for the attribute “colour”’. Each property of an object becomes its own row. The model consists of three building blocks:
- Entity: the object itself, such as a specific product with a unique ID.
- Attribute: the type of property, such as ‘colour’, ‘material’ or ‘weight’. Attributes are defined centrally and can be extended as required.
- Value: the specific content of the property for this particular entity, such as ‘blue’ or ‘250 g’.
The key point: because values have different data types (text, number, date), in practice they are not stored in a single value table, but are separated by type. It is precisely this that leads to the characteristic fragmentation which makes reading EAV databases so labour-intensive.
An example: a product spread across many tables
Imagine a T-shirt with a name, price, colour, size and a release date. In a flat model, this would be a single row with five columns. In Magento’s EAV model, the same product is spread across several tables: the name (text) goes into catalog_product_entity_varchar, the price (number) into catalog_product_entity_decimal, the date in catalog_product_entity_datetime, integer values in catalog_product_entity_int and long descriptive texts in catalog_product_entity_text. To reconstruct the complete product, the database must rejoin these tables using the entity ID. Loading a single product can therefore involve a dozen table accesses.
EAV in Magento and Adobe Commerce
Magento (and its commercial variant, Adobe Commerce) uses EAV for its core entities: products, categories, customers and delivery addresses. The historical reason for this is flexibility. A retailer can create as many of their own attributes (known as ‘custom attributes’ in Magento) as they wish in the backend, without a developer having to modify the database schema. For very large, heterogeneous catalogues with widely varying product types, this is a real advantage — a furniture retailer and an electronics retailer can run the same Magento installation with completely different sets of attributes.
The price of this flexibility is complexity and performance. Because every query must join across multiple tables, EAV is read-intensive. Magento compensates for this with aggressive caching, flat tables (aggregated, denormalised read tables) and indexers. This mechanism works, but it makes the data structure opaque — and it is precisely this opacity that becomes a problem during migration.
Advantages and disadvantages at a glance
| Strength | Weakness |
|---|---|
| Attributes that can be extended as required without schema changes | Complex, read-intensive queries (many joins) |
| A single schema for highly heterogeneous product types | Difficult to grasp and debug |
| Clear separation of structure and content | Greater hosting and caching overhead |
| Well-established and mature in Magento | Time-consuming to export and migrate |
EAV versus the entity model in Shopware 6
Shopware 6 takes a different approach. Instead of EAV, it uses a clearly defined data structure accessed via its in-house Data Abstraction Layer (DAL). Products, properties and variants have defined entities and fields. Custom fields are mapped via so-called ‘Custom Fields’, rather than through a full EAV schema. The result is a data model that is easier to read, validate and populate programmatically — at the expense of the unlimited attribute flexibility offered by Magento.
For most medium-sized retailers, this trade-off is a win: less complexity, more predictable performance, and interfaces that are easier to maintain. For very large, attribute-driven enterprise catalogues, however, the flexibility of EAV may still be valuable.
Why EAV becomes a challenge during a migration
Anyone switching from Magento to Shopware 6 is transferring data from an EAV model to an entity model. There is no one-to-one mapping between the two. Configurable products and variants are particularly tricky: in Magento, variants are attached to a parent product as a separate ‘configurable product’ structure, whereas in Shopware they are created from properties and a variant matrix. Anyone who transfers the EAV structure without careful consideration risks ending up with duplicate products, missing combinations or variants that can no longer be selected in the shop.
For this reason, a standard importer is rarely sufficient. In many projects, a mapping script or a middleware tool is required to read in the scattered EAV values, assign them to the correct Shopware field and set up variants correctly. The more customised the Magento data model is — with many custom attributes, complex variant axes and evolved category structures — the more the migration becomes a genuine data project. Understanding the EAV model is therefore essential for realistically estimating the effort involved in a Shopware migration.
EAV and Performance: Indexers, Flat Tables and Caching
The biggest practical weakness of EAV is its read performance. Because a product is spread across many tables, any storefront query would trigger a flood of joins without countermeasures. Magento addresses this with multiple layers. Indexers calculate complex data (prices, stock levels, category assignments) in advance and store it in optimised index tables. Flat tables consolidate the scattered EAV values for a product or category into a single, denormalised read table, so that the storefront does not have to go through the full EAV structure. On top of this is aggressive caching, often via Varnish and Redis.
This system works, but it comes at a price: it must be configured, monitored and rebuilt following data changes. Re-indexing a large catalogue can take a noticeable amount of time, and incorrectly configured indexers are a common cause of sluggish Magento shops. Anyone migrating away from Magento also leaves this operational complexity behind — Shopware 6 does not require the EAV-based network of indexers.
Where the EAV model comes from
EAV is not an invention of e-commerce. The pattern has been known in computer science for decades and is widely used wherever objects have a large number of very different properties that are not defined in advance. A classic example is clinical data systems: in medicine, there are tens of thousands of possible findings and measurements, of which a single patient may have only a small selection. A flat table schema with one column for every conceivable finding would be unmanageable. EAV solves precisely this problem by storing only the attributes that are actually present as rows. The same argument applies to product catalogues with hundreds of product types, which is why Magento opted for EAV at an early stage.
This ‘sparse data’ problem — many possible attributes, but only a few actually assigned per object — is the very reason EAV exists. Anyone familiar with it will also understand why, in cases where products have a uniform structure, EAV causes more trouble than it is worth.
EAV, JSON columns and other alternatives
EAV is not the only way to map flexible attributes. Modern databases offer alternatives that are simpler depending on the use case:
- JSON columns: Variable attributes are stored as a JSON document in a single column. This saves on joins, but makes targeted, indexed queries on individual attributes more difficult.
- Flat tables with many columns: Quick and easy, but inflexible and confusing when there are hundreds of optional columns.
- Hybrid models: Frequently used attributes as fixed columns, rarely used ones as JSON or additional fields. Shopware 6 is moving in this direction with its entity model plus custom fields.
The choice is always a compromise between flexibility, query performance and maintainability. EAV maximises flexibility but comes at the cost of complexity — a trade-off that made sense for Magento’s requirements but is overkill for many medium-sized online shops.
Reading and exporting EAV in practice
Anyone exporting Magento data will quickly realise that a simple table dump is not enough. To obtain a complete product record, the value tables for each data type must be merged using the entity ID and the attribute ID. In addition, the ‘store scope’ plays a role: Magento stores attribute values per store view, meaning that the same attribute value can exist in multiple language variants. An export must determine which scope level applies. It is precisely these subtleties — data type separation, attribute sets, store scopes, default values — that make extracting an EAV database a specialised task and are the reason why generic export tools often produce incomplete results with Magento.
Frequently asked questions about the EAV model
What does EAV stand for? EAV stands for Entity-Attribute-Value — the three building blocks from which the data model constructs an object’s properties.
Why does Magento use EAV? To make products, categories and customers extensible with any number of custom attributes, without having to change the database schema every time a new property is added.
Is EAV slow? EAV is read-intensive because data is spread across many tables and must be merged using joins. Magento compensates for this with flat tables, indexers and caching.
Does Shopware 6 also use EAV? No. Shopware 6 uses a clearly defined entity model via the Data Abstraction Layer (DAL) and maps additional fields using Custom Fields, rather than a full EAV schema.
Why is EAV relevant during a migration? Because Magento’s scattered EAV structure does not fit one-to-one into the Shopware model — particularly when it comes to variants — and therefore requires careful data mapping.
Can EAV data be easily exported as CSV? Only to a limited extent. A complete export must merge the value tables — which are separated by data type — using the entity and attribute IDs, whilst taking store scopes into account. Generic CSV exports therefore often result in incomplete or incorrectly mapped data.
Is EAV fundamentally a bad thing? No. For domains with a large number of optional attributes, EAV is a sensible pattern. It is only over-engineered where objects have a uniform structure — as is the case in many SME catalogues.
Further reading: a detailed, language-neutral description of the pattern can be found in the Wikipedia article on the Entity–Attribute–Value model.