Do you have any benchmark results with Clickhouse in a clustered configuration (and other db's)? Is Clickhouse expected to be run in only single node deployments?
Yea, Redshift looks like it was run on an ra3.xl (4 cores) and is comparing against clickhouse on a c6a.4xl (16 cores). I suspect if this were normalized Redshift would have an edge.
There's a lot more involved in an execution engine running complex queries that are not single table group by than just QO (though this is important). It includes things like join implementations and associated optimizations, shuffle performance (which is important even for single table queries as you scale), etc.
I stopped reading at "Incredibly, the state has not laid a single mile of track" for California High Speed rail, which is completely false. There are 119 miles under active construction and they've been putting down track since 2018.
> You are correct however that TimescaleDB requires more storage than some of these other options. If storage is the most important criteria for you (ie more important than usability or performance), then again I would recommend you to one of the other databases that are more optimized for compression. However, you can get 6-8x compression by running TimescaleDB on ZFS today, and we are also currently working on additional techniques for achieving higher compression rates.
This is a weird answer since compression is used by columnar databases like MemSQL and Clickhouse to both save on storage and accelerate queries. Compare this to using a generic a filesystem compression which would both compress worse and make the system slower.
To build on the list of features above, here's a blog post from Pandora where they go into the details of what they use MemSQL for and some of the alternatives they looked into for their use case: https://engineering.pandora.com/using-memsql-at-pandora-79a8...
I mean that an operation that needs more memory than is available will fail, but the server itself will remain operational. An simple example would be loading more data into an in-memory table (row store) than there is available memory. If you're using the columnstore then your storage won't be limited to memory.
If you have an example of the query you thought was returning inconsistent results, feel free to make a post over at https://www.memsql.com/forum/ with a repro.
The best thing to do in this situation would be to set the maximum memory on the MemSQL server via the `maximum_memory` system variable. The server will then internally manage it's memory usage against this upper bound and fail only specific operations which can't be performed without additional memory.
> data allowance of 10 million rows, and range up to a 100 million row allowance.
Only supporting up to 100 million rows seems extremely limiting for a lot of analytics use cases. What's the reasoning behind this? Does the product not scale?
The other thing that is misleading about this benchmark is that the comparison page shows results for many different DBs on vastly different hardware without any mention of price. It would be much more valuable if it attempted to normalize performance results by hardware cost.