This is very useful if you want to ship new features without constantly changing DB tables by adding new fields to models. Example scenario: - Year 0: ship v1

This is very useful if you want to ship new features without constantly changing DB tables by adding new fields to models. Example scenario: - Year 0: ship v1.0 of software with EAV table in place - Year 1: a few months later you need to store some extra attributes for a feature, so you change the code to look for these attributes if they are available, and ship updates v1.1, v1.2, v1.2.3-experimentA, etc. none of which require DB migrations. Like @lsaferite says, this is not super efficient as it requires an extra DB lookup when retrieving each object, but hey... features! (and less stressful software updates, since migrations will never break the system) Using an EAV table also allows you to ship special features only for specific clients (e.g. special integrations that apply to only certain users or custom builds). - Year 2: When shipping v2.0 you can convert all the attributes from successful feature experiments into "real" model attributes (field) and ship the v2.0 data model, possibly still keeping the EAV table around for v2.1, v2.2, etc. I think it's a nice pattern since it puts all the "DB migration risk" into a few big chunks (less upgrade paths to test), but these days Django migrations have gotten so civilized that there is less need for this...