For me, it would be a bit of a red flag to have large number of indeces on a flexible schema where each customer uses their own schema, embedded in a single tab

For me, it would be a bit of a red flag to have large number of indeces on a flexible schema where each customer uses their own schema, embedded in a single table (or collection). This could just be from my scarring at the hands of an ambitious EAV system I inherited. Step back and ask yourself why you need an index on so many fields. If your cardinality is high, your index won't help much anyhow. Think about alternate approaches - what about using one table per customer? Or using an EAV to store the truth data, then project into a MATVIEW for optimized reading via index. Try out a few options to get a sense for the design. Yes, it will take a few days to spam the database and run performance tests. However, because you are making a critical design decision and doing something less-than-standard, you need to accept the extra work - or figure out how to fit into a more standard pattern.