Photo: free stock photography (Unsplash licence) — see imprint
What custom fields really are
They are a JSON blob hanging off an existing entity. Wonderful for a handful of attributes; miserable as soon as you want to filter, sort, aggregate or join by them at scale. The database cannot index its way out of your JSON.
The switch line
The moment the data has its own lifecycle — it is created, changed and deleted independently of the product it hangs on — it is an entity, not a field. Contracts, service intervals, machine registrations: entities, every time.
Custom entities give you the whole platform
Define an entity and you get DAL access, API endpoints, admin CRUD and rule-builder access essentially for free. That is a lot of machinery you would otherwise hand-build around a JSON field, badly.
Migrating later is not free
Moving 200,000 products' custom fields into an entity means a data migration, an API contract change and a rewrite of everything that read them. Spending twenty minutes on this decision at the start is the cheapest twenty minutes of the project.
- Own lifecycle → entity. Simple attribute → custom field.
- You cannot index your way out of a JSON blob.
- Entities give you API, admin and rules for free.
Frequently asked questions
When the data has its own lifecycle — created, changed and deleted independently of the thing it hangs on. Contracts, service intervals, machine registrations: entities, every time. Until you cross that line, custom fields are genuinely fine, and most teams reach for an entity earlier than they need to. A handful of flat attributes on a product does not deserve a data model.
Because a custom field is a JSON blob hanging off an existing record. That is perfect for reading a couple of attributes and miserable the moment you want to filter, sort, aggregate or join by them at any volume. The database cannot index its way out of your JSON, and no amount of tuning changes the shape of what you stored.
Define the entity and the platform hands you DAL access, API endpoints, admin CRUD and rule-builder access essentially for free. That is a large amount of machinery you would otherwise hand-build around a JSON field, and build worse. This is the part people underestimate: the entity is not more work than the workaround, it is usually less. The work just lands earlier.
You can, and it is never free. Moving the custom fields of 200,000 products into an entity means a data migration, an API contract change, and a rewrite of everything that ever read them — including the integrations you are not thinking about right now. It is doable. It is just that twenty minutes spent on this decision at the start is the cheapest twenty minutes in the project.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer