> primary key index will be mostly cached so the cost of the indirection is much smaller than it may first appear

Not sure I follow. If it's in-memory you save having to read from disk, but you still have to walk the b-tree to go from PK to data.

https://github.com/firecracker-microvm/firecracker

"Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate."

Firecracker is AWS tech, and was behind both Lambda & Fargate. I imagine it's all the enterprisey extras built on top that cause those issues.

Yes, the 4% of the Palestinian population they've killed is definitely not a form of expression. Like somehow killing only matters if you talk about how fun it is first.

For the record that's greater than the % of Bosniaks killed in the Bosnia genocide.

Worse it invites bike shedding most of the time, where folks sit in a room nitpicking pointless details that's cathartic for the people in charge, but once again, doesn't actually do anything productive.

No. Leaderships job in this context is to set expectations of what happens next and to drive the team towards a solution that meets those expectations. No amount of trust magically makes that expectation materialize or for it to be met.

Leadership doesn't need to know what happened to set this expectation and then trust their team - who already know the details - to figure out how to meet what's expected.

Perhaps my favorite quote ever about leadership is that it's about holding a vision long enough for others to realize it for themselves, but you can't do that if you dictate and micromanage.

Yes that's the whole point, at least it's an option in the US and Europe. Good luck getting any redress from China. Anthropic was already hit with a $1.5B class-action which would be impossible against a Chinese business.

In practice even NVMe SSDs at the time were maybe 10x faster for sequential R/W and maybe only 200-500x for random I/O. Most databases in 2015 were limited by serial dependency chains like walking a B-tree to figure out what nodes to read next and couldn't max out what an NVMe was capable of. Not to mention we were stuck with libaio in 2015 that made O_DIRECT ops synchronous.

So the OPs claim of reading multiple terabytes of data in seconds on AWS in 2015 literally wasn't technically possible.

SSDs simply were not as ubiquitous in 2015 as they are today, and I didn't know anyone using them outside of mission critical systems were the cost made sense.

That sounds unlikely unless those machines had access to crazy disk I/O. A local RAID 5/10 with 8 drives would still take 30-50 minutes just to read that much data. Even with a mid-range SAN you still would have spent 15-25 minutes just reading data. This assumes 7.2K SAS/SATA since SSD/NVMe were not ubiquitous in 2015, but even with 2015-era SSDs you're still looking at half that much time spent reading.