Have you tried using them both? What were you using them for?

Yes I have used for my own projects: managing time series data (Linux resources state and helped someone to resolve performance issues with TimescaleDB last year.

hola @Michael thank you for the post!, and for using QuestDB, I also have a perspective on the comparison. For me QuestDB's model is OLAP (Online-Analytical Processing) an approach for deep analytics/reporting and aggregation of data. We are a product built from the ground up to support this model efficiently, and we focus exclusively on timeseries-type data. Because of this we can make many assumptions about the data and can control its layout on disk so that it matches RAM's. Because data are fully ordered according to a timestamp column (designated but not unique) and because our model is columnar, we can exploit hardware acceleration and direct access to data, making the use of indexes irrelevant and even worse performing. Symbols are a compression strategy rather than an indexing strategy, although it works as an index as well. Last, we provide all the required SQL so that users can make a bespoke installation of QuestDB to match exactly their use case. I am biased, 😄 . TS takes a general purpose database with a flexible model but originally intended for OLTP (Online Transactional Processing), your traditional relational-transactional models with primary-keys, foreign keys, relationships, and some level of normalization, and bolts on top a layer that makes it a closer match to OLAP.

Okay. Thanks @Miguel Arregui for the heads up on using symbols as compression strategy. So can update the post with symbols used as compression strategy? Seems everything you stated is included in the post except symbols as compression strategy.