I am also using TimescaleDB and face similar issues around the OLAP workloads. I tested Clickstream and QuestDB, both of which claim superior OLAP performance,

I am also using TimescaleDB and face similar issues around the OLAP workloads. I tested Clickstream and QuestDB, both of which claim superior OLAP performance, however the ingest rates and cardinality of my unstructured data did not perform on par with TimescaleDB in my limited tests. Lacking time, instead I implemented a number of strategies within Postgres - trading space for speed with additional computed index columns and partitioning around these, applying table layering at various time resolutions, and using Real-time Aggregates as introduced in TimescaleDB 1.7. The Real-time Aggregates make a significant improvement to performance on large datasets for very little effort and appear to be a feature well-suited to solving your problem. This has alleviated performance enough to keep me looking within the Postgres ecosystem. For now the performance is within target budgets again. Going forward, time permitting, I’ll be looking at additional Postgres plugins which target OLAP performance using combinations of columnar storage and SIMD processing: Swarm64, VOPs (https://github.com/postgrespro/vops https://github.com/postgrespro/vops), pg_strom