[ryanbooz]

(Post author)

The two big things, which we discuss at length in the post, are:

- Altinity (and others) did not enable compression in TimescaleDB (which converts data into columnar storage) and provides improvement in querying historical data because it can retrieve individual columns in compressed format similar to CH

- They didn't explore different batch sizes to help understand how each database is impacted at various batch sizes.

[PeterZaitsev]

Have you from your side followed all Clickhouse best practices?

Clickhouse design in particular suggests doing ingest request approximately once per second and if you do much more than that when you use it outside of intended usage and if you need that you usually have some sort of queue between whatever produces the data and Clickhouse.

Note the ingest in small batches also can significantly affect query performance

[ryanbooz]

Yep - it's all detailed in the post! The question is how it compares to TimescaleDB, which is an OLTP time-series database that has a lot of other possible use cases (and extensibility). I think it's very fair to explore how smaller batches work since others haven't ever actually shown that (as far as we can see) so that users that would normally be coming from a database like PostgreSQL can understand the impact something like small batches would have.

As for ingest queueing, TSBS does not queue results. We agree, and tell most users that they should queue and batch insert in larger numbers. Not every app is designed that way and so we wanted to understand what that would look like.

But CH did amazingly well regardless of that with batches above 1k-2k and lived up to it's name as a really fast database for ingest!