SlateDB follows Semantic Versioning and guarantees forward and backward compatibility for storage formats between adjacent releases. We do not currently guarantee compile-time API compatibility.

Shared deployments should move one release at a time. If several processes read and write the same database path, keep them within one release step of each other until the rollout is complete.

Stored Data#

A single database can contain a mix of older and newer SST files during normal operation. Readers and compactors must understand every format already present in the bucket. SlateDB version-checks its persistent formats and fails fast when it sees a version it does not understand.

Compression is part of compatibility too. A process can only read compressed SSTs for codecs that were compiled into that binary. If one deployment writes Zstd-compressed SSTs, every reader and compactor that touches that database needs the zstd feature enabled. Compression covers the codec feature flags.

Union clone view IDs#

A union clone combines views from several databases into one database.
Older builds can give several L0 views the same ID after a split and union.
Compaction can then read one view and remove other views that it never read.

The fix assigns unique view IDs during projection and union clone creation.
The compactor rejects requests that reference duplicate IDs.
The fix does not repair existing manifests or restore lost data.

Upgrade all processes that create clones before creating new union clones.
Writers and compactors also need the separate watermark fix to preserve unread views that share a physical SST.
An older process can still apply the faulty compaction logic.