Would you mind sharing the schema used for this comparison? Maybe I missed it in your documentation of use-cases. When implementing dynamic tags in my own model, my tests showed that your approach is very necessary.
Pretty much it's a table with time, value, tags_id. Where the tags table is id, jsonb
That may be true, but: Instead of figuring out how to meet the user's needs you're going to say the user is wrong?
What I consider to be said is that they optimize for extendability ( not just one use-case) and that those 2000 lines do a lot of things.
Including replicating optimizations that are are not easy to achieve out of the box in their and other solutions. But they mostly found a way ;)
You can say you don't want to support that usecase but someone inquired about whether you would. You said no, they're wrong to compare the two. Sounds a lot like "you're holding it wrong."
The project you cite is super-optimized for the Prometheus use-case and data model. TimescaleDB beats InfluxDB on performance even without these optimization. It's also not possible to optimize in this way in most other time-series databases.
These scripts also work hard to give users a UIUX experience that mimicks PromQL in a lot of ways. This isn't necessary for most projects and is a very specialized use-case. That takes up a lot of the 2000 lines you are talking about.