derekcollison

We are waiting on the IO abstraction for a supported Zig client (There are others though today), but this is specifically for a new initiative at Synadia that we will share more details about soon!

TigerBeetle's excellent companion blog - https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...

Here is our official response. We also plan to have a public AMA early next week for anyone interested.

https://www.synadia.com/blog/synadia-response-to-cncf

Would your company be willing to fund the development? Or would you be willing to post a PR? We would be happy to take a look.

We are waiting on demand for it. We have a bunch of folks using MQTT on NATS and NGS but no requests yet for MQTTv5 so far.

Once we see legit demand we will make sure it's supported.

We have some great work coming that allows lighter weight consumers to scale to that level and beyond. Happy to chat with folks on how we can make that work today.

We are always interested in feedback on how we can do better. Feel free to jump on our slack channel to join the community. We are actively working on the C client. Interested in more details on Python and Java issues as well.

I think entropy, in however you measure it, does influence something like a UUID generator differently than the cryptographic algorithms. What you are trying to achieve, or more importantly the condition you are trying to avoid, is different.

I agree, was simply sharing because it was a need we had, which might be a need someone else had as well. Anyone can feel free to use it or not.

I disagree, either the entropy is drained and the randomness of what the pool returns (based on OS) is compromised or you get stalled waiting for more of it and decrease performance of the generator.

https://www.google.com/webhp?q=draining+entropy+pool

Yes, but most UUID when moved across networks are translated to hex, so 32 bytes/characters whereas NUID's are 22 bytes, so generally a savings of 10 bytes per when stored as a string.

UUID V4 is ~900ns/op, NUID is ~60ns/op, so 15X speedup, or 1500%.

I am deeply saddened by this news. I remember trying to convince Ezra to join us to help out with CloudFoundry. I, like others, knew Ezra through the Ruby community where he was a larger than life presence. My thoughts are with his son, his family and friends.

The test is specific to a new NATS server written in GO (gnatsd). I described in more detail above the tests and what they do, but suffice it to say that it does test the message processing overhead of the server.

It is not, but its on my TODO list, and I have also observed similar behavior at times. I have taken care to make sure the synchronization is efficient, but running the test is needed to get the real results.

It is not one big write, but optimizations around msgs/write using buffering are used in clients, with obvious care to balance latency and throughput. In the benchmark, the write buffer is 16k, so it is flushed automatically via Go's bufio when it hits that mark, and then I flush it again when the loop is complete, flushing the remainder of the outbound buffer. I then use a PING/PONG, which is part of the NATS protocol, to only stop timing when the PONG returns, and I know all messages have been processed. NATS does have a verbose protocol flag that has all protocol frames ack'd with either +OK or -ERR.

That is correct, I am only attempting to measure the efficiency of the messaging processing engine within the server. I did want to include the network stack and the buffering portion, as well as the framing, protocol parser, and the subject based routing.

The simple benchmark is testing throughput of a messaging system, specifically a new server written in Go. Both the client and server are on the same machine, but going over a tcp/ip socket. The Pub benchmarks send messages and then make sure the connection is flushed, meaning all messages have been completely processed by the server. Processing in this case means framing, protocol and routing logic. The PubSub versions test sending and receiving all the messages back in the client, with a few variations on using multiple connections and distributed queuing.

We plan on doing that, appreciate the feedback.