ruw1090

No tax on tips does not apply to payroll taxes (FICA).

The Xenomorph term wasn't created by the fandom. It was first used in-universe in "Aliens".

Citation?

Sure, but given multiple opportunities (every time the clip gets brought up) to condemn it, he hasn’t. This should tell you enough.

Close, but in database years it was actually already in its mid life crisis.

The snowflake clusters are several factors bigger (and more expensive) than almost all of the comparison points.

That makes sense, thanks for clarifying. I got confused by the UI.

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.

The total estimated cost has increased by 44 Billion. Only ~10 billion has been spent on the project so far.

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.

What is the benefit of shipping data to the GPU for execution if the data is on S3 or HDFS? Won't most of the cost of the query be I/O?

It looks like you had to rewrite the queries pretty significantly to get them to run on all three. Redshit/Bigquery don't support rollup/grouping sets/intersect/except etc. which the TPCDS spec queries have. Is there a reason you don't mention this in the blog post? SQL surface area seems like a pretty important thing to consider when choosing a DW.

So blazing db mainly uses gpus to speed up compression/decompression? How do gpus help with partitioning and data skipping?

citation?

very interesting. Do you have a link to documentation? I'd like to take a look before I try it out.

It looks like they benchmarked against MemSQL 3.2, which is nearly 2 years old and Hive .11, which is close to 3 years. Not sure how out of date the other comparisons are.

While I love to hate on MongoDB as much as the next guy, this behavior is consistent with read-committed isolation. You'd have to be using Serializable isolation in an RDBMS to avoid this anomaly.

It's actually quite common throughout the world for railroads to have their own police force.

http://en.wikipedia.org/wiki/Railroad_police