Ah appreciate it! And I always hold gamedev in the highest regard—where it’s at!

Thanks! It was definitely a highlight working on such bleeding-edge technologies with crazy smart people. Pouring over custom PowerPC CPU Errata was divine.

Oh, and we only had (if I recall) 1ms per frame on one core to do all our payload packaging and dequeue messages from the circular buffer. Thats' where the 20k/s hard limit came in... we could have handled SO much more. Our entire message usually landed around 100-150 bytes if I recall, using bitpacked structures.

One thing I didn't anticipate: Memory stomping would result in everyone pointing fingers at our department, because we would inevitably be the ones that would crash (usually with our hardening asserts). We had to start flagging our memory blocks as unwritable when our thread was idle during debug mode, so that offenders would crash when they touched our memory.

The author of SlateDB, Chris Riccomini, is an angel investor in TigerBeetle.

However, TB here is also providing a Replicated State Machine with consensus and strict serializability, in front of object storage, to provide remote object storage capacity and recovery, but with local NVMe latency and without sacrificing consistency or durability.

TB navigates the entire design space, specializing for both hot and cold (transactional) data.

The more you zoom, it’s a stronger set of guarantees in terms of safety and performance.

Ah I appreciate your kind words, Aditya!

This was a team effort: the object storage connector, the scale test, the visualization, the slides, even provisioning the hardware had its challenges!

Oh most certainly; I am remiss to have not included the group effort in my comment, particularly as a person surrounded by theatre and film making friends.

Still, for the same reason, I have some idea of why their productions turn out well (or not). Where "well" is "a story well told", not "successful" as in "did well at the box office". The why is usually one person who keeps asking the questions and making the decisions that take the story from imagination to imagination via screen or floor.

Something tells me your doubtlessly excellent "production team" (in film terms) will agree with my original comment :)

And I suppose we did minimize the preprocessor somewhat with comptime… :D

Thank you Andrew, you always have our full support.

The author graciously gifted the domain to us and we’re literally days away from launching original TigerStyle here.

That's really nice of the author and awesome to hear. Would love to see TigerStyle be published in a similar format and expanded upon with more detail be great for referencing with my colleagues. Would love to adopt it on projects or some of the rules at least

Oh that's very nice of them.

You would use TigerBeetle for everything: not only the final purchase transaction, but the shopping cart process, inventory management and queuing/reserving.

In other words, to count not only the money changing hands, but also the corresponding goods/services being exchanged.

These are all transactions: goods/services and the corresponding money.

Appreciate your kind words, Kelsey!

I searched the recent history of our community Slack but it seems it may have been an older conversation.

We typically do code review work only for our customers so I’m not sure if there was some misunderstanding.

Perhaps the assumption that because we didn’t say anything when you pasted the code, therefore we must have reviewed the code?

Per my other comment, your benchmarking environment is also a factor. For example, were you running on EBS?

These are all things that our team would typically work with you on to accelerate you, so that you get it right the first time!

Yeah it was back in February in your community Slack, I did receive a fairly thorough response from you and others about it. However then there were no technical critiques of the Go benchmarking code, just how our PostgreSQL comparison would fall short in real OLTP workloads (which is fair).

Yes, thanks!

I don’t think we reviewed your Go benchmarking code at the time—and that there were no technical critiques probably should not have been taken as explicit sign off.

IIRC we were more concerned at the deeper conceptual misunderstanding, that one could “roll your own” TB over PG with safety/performance parity, and that this would somehow be better than just using open source TB, hence the discussion focused on that.

Of course, there’s nothing new except shining a spotlight (and coining the rule!).

Yes, write last to the system of record, read first from the system of record. Or in other words, commit to the system of record, and then read from the system of record to see what's committed.

(This is similar also to how chain replication preserves consistency.)

If you read first and write last isnt that the opposite of committing and then reading to see what is comitted?