Learn NATS - Latest Stable Features (v2.14)

#Introduction

After mastering operations and troubleshooting, it's time to look ahead. Episode 20 covers the latest stable NATS release — v2.14 — and the features it brings in 2026. You'll understand the release evolution, how to upgrade safely, and the new features worth taking advantage of.

This is also the technical epilogue: episodes 21 and 22 will weave all the knowledge into a production architecture and a final reflection.

#Release Evolution

#From v2.10 to v2.14

The NATS release path moves steadily and conservatively:

v2.10 (2023) --> v2.11 --> v2.12 (2025) --> v2.14 (2026)

The v2.12 (2025) -> v2.14 (2026) release shows NATS jumping from 2.12 to 2.14 without a 2.13 series — the numbering skips because version 2.13 was used for internal development and never released publicly. Every release brings performance and security improvements without changing the core philosophy.

#The Backward Compatibility Philosophy

NATS strongly preserves backward compatibility. Connections, subjects, streams, and consumers created in v2.10 generally keep working in v2.14 without configuration changes. This differs from some brokers that revamp their storage format between versions.

#Upgrade Guidance

#Checking Versions Before an Upgrade

Before upgrading, inventory the running versions:

nats-server -v
nats --version

nats-server -v shows the server version, nats --version the CLI version. Make sure both are compatible — a CLI much newer than the server generally still works, but it's safer to raise them together.

#A Gradual Upgrade Strategy

For clusters, upgrade nodes one by one:

kubectl rollout restart statefulset/nats
kubectl rollout status statefulset/nats

kubectl rollout restart statefulset/nats performs a rolling upgrade: one replica is updated, waits to become healthy, then the next replica. The cluster keeps its quorum as long as not all nodes restart at once. Always back up JetStream data before a major upgrade.

#The 2026 Feature: High-Throughput Publishing

#A Faster Publish Path

The most prominent v2.14 feature is high-throughput publishing to JetStream: the server buffers messages and writes them to disk in groups, drastically reducing per-message fsync.

nats-server -c nats.conf --jetstream

The nats-server -c nats.conf --jetstream server enables the new publish path by default. Clients just use async publishing or batching as covered in episode 16 to feel the benefits.

#The 2026 Feature: Server-Side Message Scheduling

#Orchestrating the Flow Without the Client

v2.14 adds server-side message scheduling: the server controls when consumers receive messages, adapting to capacity and load, without clients managing timing.

server manages the queue -> deliver per consumer capacity
consumer busy -> messages held, delivered when ready

The server manages the queue model lets many consumers share one stream without competing. Combined with flow control, message delivery becomes much smoother.

#The 2026 Feature: Sourcing and Mirroring Improvements

#Interest and WorkQueue Support

A key v2.14 improvement is sourcing and mirroring for Interest and WorkQueue streams. Previously, mirroring a WorkQueue stream was problematic because each message may only be read once; now NATS handles the synchronization correctly.

name: ORDERS_DR
mirror:
  name: ORDERS

The mirror block now works reliably for all retention policies including WorkQueue. This opens the door to cross-region DR with job queue patterns, which were previously hard to implement.

#The 2026 Feature: in_client and out_client Metrics

#Per-Client Traffic Metrics

v2.14 exposes in_client_* and out_client_* metrics — the number of bytes and messages in and out per client:

curl -s http://localhost:8222/connz?subs=1 | python3 -m json.tool | grep -i "in_msgs\|out_msgs"

The in_msgs and out_msgs output from /connz shows traffic volume per connection. With these metrics, you can identify clients flooding the system or inactive clients — the foundation of capacity planning and alerting.

#Conclusion

Episode 20 updated your knowledge to the latest release: the release path from v2.10 toward v2.12 then v2.14 with backward compatibility principles, the safe rolling upgrade strategy, and the 2026 features — high-throughput publishing, server-side message scheduling, sourcing and mirroring improvements for Interest and WorkQueue, and the in_client and out_client metrics.

Key takeaways:

• NATS jumps from v2.12 to v2.14; the 2.13 series was never publicly released.
• Backward compatibility is strictly preserved across versions.
• Cluster upgrades use rolling restarts so quorum is maintained.
• High-throughput publishing buffers messages and reduces per-message fsync.
• Server-side message scheduling orchestrates the flow without client burden.
• The in_client and out_client metrics help capacity planning.

In episode 21 next, we'll discuss production-ready architecture — designing a 3 or 5-node cluster with JetStream, accounts and JWT, TLS, monitoring, and disaster recovery via cross-region mirroring, then application patterns: event-driven microservices, request-reply APIs, job queues, and streaming pipelines. All your knowledge starts coming together into one whole.