The Entity-Attribute-Value (EAV) model is a solution that initially looks very clever.
It allows developers to add new fields without changing the database structure.
For this reason it has often been used in CMSs, e-commerce platforms, and systems that support dynamic fields.
The idea is simple: instead of storing data in tables with fixed columns such as name, surname, or age,
data is saved as generic rows composed of entity, attribute, and value.
This makes the database very flexible, but that flexibility comes with a cost.
Why it is still used today
EAV is still widely used because it allows systems to support custom fields,
add extensions without modifying the database schema,
and keep a structure that appears stable over time.
For these reasons it still appears in many modern projects, including those written in PHP.
The problem is that what looks convenient at the beginning can become complicated as the project grows.
Main problems
The first issue is query complexity.
In a traditional relational database, reading data is simple and direct.
With EAV, even basic operations often require multiple joins,
data transformations, and logic that is harder to optimize.
The second issue is performance.
EAV tables tend to grow very quickly,
indexes become less effective,
and the database has to work harder to perform fast searches.
There is also a data integrity problem.
In a traditional relational model, the database itself can enforce types, constraints, and consistency.
With EAV, many of these guarantees move into the application code,
which can make the system more fragile.
Finally, EAV makes the database harder to understand.
In a relational system the structure is visible directly in the tables.
In an EAV system the real structure is hidden inside the data itself
and often has to be reconstructed by reading queries and application logic.
Why it made sense in the past
Historically, EAV also became popular because modifying database tables used to be risky.
Operations such as ALTER TABLE could lock large tables or require long downtime.
To avoid these problems, many systems preferred to use a generic structure.
Today, however, modern relational databases handle schema changes much better.
In many cases adding a column is much simpler and safer than it used to be.
Conclusion
The real advantage of EAV is flexibility,
but that flexibility often comes at the cost of slower queries,
more complex code,
less clarity,
and weaker data management.
For many modern systems, modifying the database structure directly can be a better choice:
clearer, faster, and easier to maintain over time.
Inside MilkAdmin I decided to experiment with this idea by building an admin form system
that, instead of using EAV, modifies the structure of the original database tables directly.
giuliopanda
/
milk-admin
Open-source PHP admin panel and dashboard built with Bootstrap 5 — relational CRUD generator, authentication, REST API, CLI, modular architecture, MySQL & SQLite.
Milk Admin
Milk Admin is a PHP admin panel designed for building backoffice administration panels.
It focuses on explicit control, relational CRUD flows, and long-term maintainability, avoiding heavy abstractions and rigid resource-based architectures.
It focuses on explicit control, relational CRUD flows, and long-term maintainability, avoiding heavy abstractions, and rigid resource-based architectures.
Milk Admin provides a stable and structured backend core, modern PHP 8+ code, and minimal dependencies — allowing developers to focus on real business logic instead of framework workarounds.
Project Status
Milk Admin is currently in Beta.
The core architecture is stable and actively evolving, while APIs and features may change.
Official links:
Website ·
Documentation ·
Live Demo
When Milk Admin is a good fit
- You are building an admin panel or internal backoffice
- Your data model is relational and nested
- You want full control over the admin flow
- You prefer writing plain PHP…

Top comments (0)