How productive is the product feature schema where feature values ​​are stored in two JSON fields (feature value and their structure?

Question

PostgreSQL

For a very long time I was looking for an alternative to EAV for an online store on Django. The task was not only to implement a variable number of product attributes, but also to implement their ordering and nesting into attribute groups, namely: a
product can belong to several categories. The order of the categories is important because they define groups of attributes specific to each category. Within attribute groups, attributes are defined that can be of several types by data type - number, text, one value from the list, a set of values ​​from the list. Just one JSON field is a good option, but it describes an arbitrary number of attributes but does not specify their order and nesting. I had to farm two. The screenshots show what data structure is in them.
parameters = models.JSONField: The key is attribute_group id - attribute_id (an attribute can have a different value depending on which attribute group it belongs to).

parameters_structure = models.JSONField

Written widget for admin:
class ProductAttributesField(forms.MultiValueField) which looks like this

.
Nesting is determined by tables and relationships between them:
Product, Category, ProductInCategory, AttrGroup, AttrGroupInCategory, Attribute, AttributesInGroup, AttributeValue (variants of fixed values ​​for selection)
These tables are needed in fact for the admin panel and store the names of these entities themselves. It looks like this:
In the form of a product (inline categories can be dragged to change the order of categories)


list of categories:


in the category editing form:


Editing an attribute group:


Editing a product attribute:


Everything looks like EAV in the admin interface, but under the hood, any change in the data structure (added an attribute to an attribute group, changed the order of categories) overwrites the parameters_structure field of each related goods. All in order to be able to refer only to the product parameters when selecting and filtering products, and to parameters and parameters_structure when rendering product characteristics.
I have now implemented this logic in SAVE and DELETE intermediate tables (ProductInCategory, AttrGroupInCategory, AttributesInGroup) but in the process of transferring from there to the forms of changing the models themselves (Product, Category, AttrGroup)

There is still a lot of work, but is it justified? Will I get a speed gain compared to EAV, or maybe there was an easier solution?