steepben

https://blog.benjscho.dev/

Ankush has moved on to Snowflake now, but he was previously at AWS.

Yes it's a large chunk, but not everything! Marc had a comment on bluesky regarding this:

Many SQL aggregations are monotonic operations (e.g. MAX, SUM, etc) that can be partially completed on each node and then post-merged. Some (e.g. DISTINCT) can be transformed into monotonic ops with some effort. Some aren't possible to do this way. (Ref on monotonicity: arxiv.org/pdf/1901.01930)

The benefit of this is that a lot more work is done _close_ to the data. The trend is that bandwidth is getting larger in data centers, but latency isn't improving at the same rate. Reducing the number of round trips between QP and storage greatly improves the overall query latency, even if you have to do more work on the storage.

There's a blog with more technical details: https://aws.amazon.com/blogs/database/introducing-amazon-aur...

It provides strong consistency for cross-region transactions

It's Postgres compatible, so not exactly non-portable

There's a blog on the technical details here: https://aws.amazon.com/blogs/database/introducing-amazon-aur...

According to page 128 of their S-1 filing [0], their claims bot "AI Jim" processes claims without human intervention in a third of cases, including automatically denying claims. So either the second tweet in the thread is a lie, or their S-1 filing is a lie. This was pointed out by Rachel Metz [1].

[0] https://sec.report/Document/0001047469-20-003416/#cy40510_bu... [1]: https://twitter.com/rachelmetz/status/1397625251257753606?s=...

Nope! Actually going off better info now it looks like they WERE using rows, but it was in the old .xls format instead of .xlsx which limits to 2^16 rows

https://twitter.com/standupmaths/status/1313149987707072512?...

Columns, they were using a column per case instead of a row per case.