EAV doesn't scale very well at all. The main problems are that if you allow a customer to put their own entities in and filter on these they might put like 20 different entities in. A "normal" EAV query would then consist of 20 self joins with a filter for each join on the specific attribute that the user wants to filter on.

Imagine Firstname is one and lastname is another. If they want to filter on firstname = David and lastname = Smith they do something like:

SELECT e1.entity_id FROM EntityAttributeValue e1 JOIN EntityAttributeValue e2 ON e1.entity_id = e2.entity_id WHERE e1.attribute = 'first_name' AND CAST(e1.value AS STRING) = 'David' AND e2.attribute = 'last_name' AND CAST(e2.value AS STRING) 'Smith';

The more filters you add the more the whole thing becomes slow as traditional indexing doesn't work with this schema.

Note also the casting here also makes the thing slower as you need to cast you values which are generic to something more specific (think age). This casting prevents index usage.

Also EAV kind of prevents you putting anything you want as the value column needs sized to fit the thing you want and you need to know it's type to be able to create a filter query.

I've worked with a very heavy EAV style system where essentially the entire dataset was put into a single table. That company is dead we couldn't scale for our customers demands and it was too expensive to sell the software to our customers.

To me it seems a better approach to this JSON column is to make the types designed by the customer normal attributes on the notification table but shard this per customer. So each customer you have has their own notifications tables with their own indexes. You could also instead of tables shard the customer specific data into their own database instead.

This scales better than a single multi-tenant table per customer.