leentee

What I get from this is frontier model capabilities are being stagnant.

Look at their benchmark charts to understand how desperate they're. A lame duck now.

From my experience optimizing an OLAP database with high concurrency; lots of time the bottleneck is memory speed.

No backup, no replica? Such a shame.

I think the new UPDATE implementation is great, however its impact is limited. As a heavy CH user, our typical use case is inserting rows with some columns are missing, then backfill these columns later on (and I've seen such pattern in many places). In my previous company (big Chinese tech), we developed a customized solution for ingesting partial columns (that's long time ago when FINAL is still a pita). Our current solution is using aggregating merge tree with anyLast and nullable columns. UPDATE == INSERT and that's it. Imagine doing it with millions of UPDATE queries, that'll be nightmare.

First, I think the article provides false claim, the solution doesn't guarantee durability. Second, I believe good synchronous code is better than bad asynchronous code, and it's way easier to write good synchronous code than asynchronous code, especially with io_uring. Modern NVMe are fast, even with synchronous IO, enough for most applications. Before thinking about asynchronous, make sure your application use synchronous IO well.

Yet another database built on ByteKV. Back then when I was in ByteDance, all infrastructure were more or less using ByteKV for data and metadata storage. Unfortunately we had less information about this technology because dev are in China (only thing I'm quite certain is that it's based on FoundationDB). Would be an interesting if they can write a paper about it.

I believe the author means "the best transactional k/v store"