I completely agree. Huge respect and appreciation to Joran & team.
Thank you Andrew, you always have our full support.
Readit Newsjorangreef commented on Synadia and TigerBeetle Pledge $512k to the Zig Software Foundation tigerbeetle.com/blog/2025... · Posted by u/cratermoon
jorangreef commented on Tiger Style: Coding philosophy (2024) tigerstyle.dev/... · Posted by u/nateb2022
The attribution to TigerBeetle should be at the top of the page with a link to the original tigerstyle, not buried at the bottom. Right now it reads like official TigerBeetle content until you scroll down, which isn't fair to either you or the original team.
The author graciously gifted the domain to us and we’re literally days away from launching original TigerStyle here.
jorangreef commented on Building a high-performance ticketing system with TigerBeetle renerocks.ai/blog/2025-11... · Posted by u/jorangreef
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.
jorangreef commented on Building a high-performance ticketing system with TigerBeetle renerocks.ai/blog/2025-11... · Posted by u/jorangreef
Agree with the above, we built and run a ticketing platform, the actual transaction of purchasing the ticket at the final step in the funnel is not the bottleneck.
The shopping process and queuing process puts considerably more load on our systems than the final purchase transaction, which ultimately is constrained by the size of the venue, which we can control by managing the queue throughput.
Even with a queue system in place, you inevitably end up with the thundering heard problem when ticket sales open, as a large majority of users will refresh their browsers regardless of instructions to the contrary
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.
jorangreef commented on Building a high-performance ticketing system with TigerBeetle renerocks.ai/blog/2025-11... · Posted by u/jorangreef
Ok your comment made me double check our benchmarking script in Go. Can confirm we didn't instantiate a new client with each request.
For transparency here's the full Golang benchmarking code and our results if you want to replicate it: https://gist.github.com/KelseyDH/c5cec31519f4420e195114dc9c8...
We shared the code with the Tigerbeetle team (who were very nice and responsive btw), and they didn't raise any issues with the script we wrote of their Tigerbeetle client. They did have many comments about the real-world performance of PostgreSQL in comparison, which is fair.
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!
jorangreef commented on Building a high-performance ticketing system with TigerBeetle renerocks.ai/blog/2025-11... · Posted by u/jorangreef
It's almost like stored procedures were a good idea.
If only. But you also need to fix the internal concurrency control of the DBMS storage engine. TB here is very different to PG.
For example, if you have 8K transactions through 2 accounts, a naive system might read the 2 accounts, update their balances, then write the 2 accounts… for all 8K (!) transactions.
Whereas TB does vectorized concurrency control: read the 2 accounts, update them 8K times, write the 2 accounts.
This is why stored procedures only get you typically about a 10x win, you don’t see the same 1000x as with TB, especially at power law contention.
jorangreef commented on Building a high-performance ticketing system with TigerBeetle renerocks.ai/blog/2025-11... · Posted by u/jorangreef
Thanks for reaching out. I shared this benchmarking script with your team when we tested Tigerbeetle, but this is it again: https://gist.github.com/KelseyDH/c5cec31519f4420e195114dc9c8...
Was there something wrong with our test of the individual transactions in our Go script that caused the drop in transaction performance we observed?
Thanks Kelsey!
We’d love to roll up our sleeves and help you get it right. Please drop me an email.
jorangreef commented on The write last, read first rule tigerbeetle.com/blog/2025... · Posted by u/vismit2000
One of the real pleasures of HN is that it provides for a clockwork-like enthusiastic rediscovery and re-articulation of basic computer science and systems concepts.
It's almost enough to make me believe in the independent existence of Platonic truths. Almost.
Of course, there’s nothing new except shining a spotlight (and coining the rule!).
jorangreef commented on The write last, read first rule tigerbeetle.com/blog/2025... · Posted by u/vismit2000
The article mixes two things: (1) That you should (depending on requirements) have one system of records while the other systems are merely systems of reference, and (2) that in that architecture, when (*) you write to both systems or read from both systems for the same logical record, then in the writing case you have to write to the system of records last, and in the reading case you have to read from the system of records first. The article however doesn’t make it clear that the titular rule is specifically (2), and that it is conditioned on (1) and on (*).
I have no suggestion for a better name off the top of my head. The issue I see is that you already have to know well its context and when it applies, also in order to not misremember it as “Write First, Read Last”, and to not mistake it as LIFO, or to relate it to a read-modify-write scenario in which you naturally would read first and write last anyway, though in a different sense. You see how the name is confusing?
I’m not convinced that it’s confusing, or that there’s a better alternative—but I appreciate your critique.
Do you not think if someone can remember those four words, they’re less likely to get it wrong?
If you could contribute some better suggestions we could consider them!