nats.go

JetStream (not NATS) has a built-in key/value store. Relevant thread (old, from 2023): https://github.com/nats-io/nats.go/discussions/1507 someone did some benchmarks in 2025: nats bench kv put --size="128" --msgs 1000000 --storage file 1m3s → Pub stats: 15,656 msgs/sec ~ 1.91 MB/sec nats bench kv get --size="128" --msgs 1000000 59s → Sub stats: 16,720 msgs/sec ~ 2.04 MB/sec I have personally not used this though.

> 5.9k stars, 727 forks, 132 contributors: https://github.com/nats-io/nats.go That's the NATS Go _client_. The server project is https://github.com/nats-io/nats-server 17k stars, 1.5k forks, 160 contributors

Die, how? It's a vibrant project with 5.9k stars, 727 forks, 132 contributors: https://github.com/nats-io/nats.go Yes, the legal fight may end up permitting the clawback of the trademark, in which case the project will carry on under a different name and repo. But that's not death, that's fork. The source is out of the bag under Apache 2.0 and there's no putting that back in the bottle.

See https://github.com/nats-io/nats.go/tree/main/jetstream#readm...

(note that NATS Streaming is a now deprecated predecessor to NATS JetStream) Pull does have advantages over push (e.g. one-to-one flow control since the transfer of the messages is initiated by the client (pull requests)), and they are basically functionally equivalent (only thing push can do that pull can not is send a copy of all the message to all the subscribers, should you ever need it). They both exists because historically push came first and then pull later). As a developper using NATS JetStream you should really not have to worry about push or pull, you should just care whether you want to consume the messages via call back or via an iterator or via fetching batches, after that whether pull or push is being used underneath the covers is irrelevant to you. And this is exactly how it is in the new JetStream API (https://github.com/