Upgrades
Upgrade without downtime or stranded data
Every persistent file carries a versioned envelope, every signed artifact declares its scheme, and every reader dispatches on both. Formats migrate on the policy that suits them, deprecations run on a clock, and new binaries roll across a Raft group with per-node rollback.
The envelope
Every file says what it is
Twenty-eight format kinds are registered, covering everything the engine writes down, from the WAL and the heap to lake manifests, the raft log, the audit hash chain, and zyron.toml. Every kind carries the same identity, in whichever of three framings suits the file.
The framing changes with the file. The identity does not, so a reader always knows which version it is holding.
Sixteen of the 28 registered kinds. The lake artifacts, the raft log, and the configuration file sit in the same registry as the storage formats.
Migration
Migration without a maintenance window
An upgrade ships a migration function for every format it touches, and each format declares the policy it wants. Once the migration is behind it, the steady-state cost is a single integer compare when a file is opened.
eager
The upgrade migrates the files it owns up front, and the old version is gone when it finishes.
lazy
Files migrate as they are opened, so the cost lands on the paths that touch them.
coexist
Old and new versions stay readable side by side, and nothing has to be rewritten to move on.
A reader window three versions wide
A build reads the current version plus the two before it. That is wide enough to skip a release without stranding files, and narrow enough that the reader code stays something a person can hold in their head.
CI retires old readers on schedule
Every reader registers a retirement date, and the build fails once that date has passed. Old code cannot linger quietly because nobody remembered to delete it.
28 kinds
Registered format kinds
3 readers
Current version plus two older readers
1 integer compare
Steady-state overhead on file open
Signatures
Rotate a signature scheme without a wire change
Signed artifacts declare their scheme the same way files declare their format. Each artifact kind has a current scheme and a deprecating one, and an overlap window keeps both accepted while the rotation runs.
JWTs
A token names the scheme that signed it, and the verifier picks the matching one instead of assuming.
X.509 certificates
Certificate signatures resolve through the same registry as everything else Zyron verifies.
Custom binary artifacts
Zyron's own signed binary artifacts carry a scheme tag on the wire, so a rotation is a registry change.
Six schemes registered today
post-quantum readyAdding a post-quantum scheme means registering it, not changing the wire or the code that verifies against it. The same dispatch backs the tokens and certificates behind the authentication and audit surface.
Catalog and objects
The catalog and the SQL people wrote
Files are the easy half. The catalog has to move with them, and so does the SQL a tenant already wrote and depends on.
Schema evolution registry, 33 tables
Catalog changes go through a registry covering 33 tables, with a per-row migration function for each change. Those functions run in-transaction at upgrade time, so the catalog either arrives at the new shape or stays at the old one.
AST-based user-object rewriter
User objects are rewritten through the parser's AST rather than by matching text, across every object kind that holds SQL.
safe
The rewrite is unambiguous, and applying it needs nobody to read it first.
ambiguous
More than one rewrite is defensible, so the choice goes back to the tenant.
unsafe
The change cannot be made mechanically, and the object is reported rather than touched.
Rewrite policy is the tenant's call
Each tenant sets how much the rewriter may do on its own, from applying the safe cases through to touching nothing until a person says so.
-- Dry run the rewrite for one object before anything changes
EXPLAIN REWRITE FOR OBJECT sales.monthly_revenue;The dry run reports what the rewriter would do to one object, in the same SQL surface as everything else.
Deprecation
Nothing disappears without notice
Anything on the way out moves through four stages, and every stage is a window with an end date on it. A caller hears about it at the warn stage, not at the moment the call stops working.
Each stage carries its own window, and the migration guide for the change is generated rather than written by hand.
Time-bounded windows
Each stage runs for a set window rather than until somebody notices, so the end date is known from the start.
Rate-limited warnings
Warnings are rate limited per tenant, so a hot loop reports the problem once instead of burying the log in it.
Generated migration guides
The guide for each deprecation is generated from the registry, so it says what the change actually was.
Rolling upgrades
New binaries across a Raft group
The auto-upgrade orchestrator moves a cluster from one release to the next without taking it down. A cluster tracks a channel, and the rollout rides the same Raft group that commits its writes.
Four channels. Three of them follow a release train, and a pinned cluster follows a version instead.
Signed release manifest
A release is described by a signed manifest. Nodes take their next version from it, not from whatever binary happens to land on disk.
Compatibility gate
The gate decides whether the jump is legal, and plans a chain of upgrades when a direct hop is not.
Rolling upgrade over Raft
Nodes take the new binary one at a time with drain coordination, so the Raft group holds a quorum the whole way through.
Health-baselined rollback
Every node is measured against its own health baseline once it is back. A node that misses rolls itself back, and the cluster pauses the rest of the rollout.
Maintenance windows
The rollout is confined to the windows an operator configures for it, and waits outside them.
Federation-aware gating
An upgrade that would leave a peer cluster on an incompatible version is blocked before the first node moves.
Operators
Four subcommands over all of it
The whole substrate is visible from zyron-ctl, from what a file on disk claims to be through to verifying a release before it reaches a channel.
Inspect what version every persistent file is carrying.
Batch migration, and the admin trigger for a rollout.
Read the lifecycle stage of anything on the way out.
Verify a release in CI before it reaches a channel.
# What is on disk, and what version each file claims
zyron-ctl format
# Migrate in batch, or trigger the rollout as an admin
zyron-ctl upgrade
# Lifecycle state, and release verification in CI
zyron-ctl deprecation
zyron-ctl releaseThe same binary that ships with every build. Take it from the download page and point it at a running cluster.
Running in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.