DreamDB

Versions

DreamDB has four version numbers that move independently: the protocol, the two SDKs, and this site. They are not meant to match, and reading one as the others is the usual source of confusion.

What to use today

VersionInstall
JavaScript SDK0.5.4npm install @dreamlake/dreamdb@0.5.4
Python SDK0.0.12pip install dreamdb==0.0.12
ProtocolPer-capability versionsConsult the owning spec and package version; not all capabilities ship in both SDKs

Both SDKs are compiled from the same Rust core. Mixing them is intended for shared supported capabilities: ingest in Python, read in JavaScript. This release adds query-local rerank controls and shared-core GC repairs, retaining entity keys, progressive geometry and structured arrays; consult the feature guide for capability boundaries rather than assuming every operation is available on every SDK target.

What each number means

Protocol. The 28 specification documents, through geometry (0027), have per-document maturity and per-capability versions. Normative means a contract is adopted within its scope, not that every SDK implements it; the encryption format is one explicit counterexample. Python 0.0.12 and JavaScript 0.5.4 include dense/ragged/CSR arrays, optional entity keys and progressive geometry; see feature examples and limits. Never infer a package's capabilities from the site's protocol inventory alone.

JavaScript SDK — @dreamlake/dreamdb. Two distinct lineages share this name, which is worth knowing before you read anything written before July:

RangeWhat it was
0.1.0 – 0.1.2A hand-written TypeScript implementation. Deprecated. Its write path produced objects other implementations cannot read — non-BLAKE3 hashes, insertion-ordered CBOR, microsecond time anchors, no compare-and-swap on refs. Reads were fine
0.2.0 – 0.3.1The Rust core compiled to WebAssembly, read-only while the port completed
0.4.0 and laterIsomorphic: read and write, browser and Node

Python SDK — dreamdb. Version 0.0.x throughout. It has been the write path since the beginning and never had the conformance problem the TypeScript lineage did. Reopening a dataset with a trained spatial index was broken before 0.0.5.

This documentation site. The number in the header chip is the site's own version, not the product's. Each release is also published at an immutable URL so a link into the docs keeps meaning what it meant.

Release history

The JavaScript SDK:

VersionDate
0.5.42026-09-10Current. Query-local rerank options and shared-core GC retention repair
0.5.32026-09-10Entity keys, progressive geometry, ragged/CSR, L2 and graph/planning improvements
0.5.22026-09-07Typed arrays, VideoItem reads, CMAF ingest, and bounded streaming reads
0.5.12026-07-29
0.5.02026-07-29
0.4.02026-07-28Write path returns; isomorphic browser + Node
0.3.0 – 0.3.12026-07-25 – 07-26
0.2.0 – 0.2.12026-07-14First WebAssembly build
0.1.0 – 0.1.22026-05-25 – 06-02TypeScript implementation, deprecated

The Python SDK:

VersionDate
0.0.122026-09-10Current. Query-local rerank options and reference-mode GC retention repair
0.0.112026-09-10Entity keys, progressive geometry, ragged/CSR, L2 and graph/planning improvements
0.0.102026-09-06Typed arrays, VideoItem reads, and bounded large-data paths
0.0.92026-09-05Protocol and correctness rollup
0.0.82026-08-10Large-read timeout policy
0.0.72026-08-08
0.0.62026-07-31
0.0.52026-07-29Fixes reopening a dataset with a trained index
0.0.42026-07-29Adds Linux ARM wheels
0.0.32026-07-07
0.0.22026-06-02
0.0.12026-06-01First published wheel

Compatibility

Data outlives SDKs, but capability support must match. Package versions alone do not establish compatibility. A consumer must understand the relevant stored forms or explicitly refuse before entering their semantics; it must not silently ignore critical extensions. Apply this to readers, writers interpreting parent state and collectors across every retained root, not just the latest Ref. Conformance vectors do not prove that every released SDK implements every form. For reference-mode vector data, upgrade or fence old collectors even when current readers work; see GC upgrade guidance.

The legacy namespace still reads. Algorithm identifiers were renamed from vortex.* to dreamdb.*. Readers across the whole stack accept both, so data written before the rename still opens.

Pre-1.0 means the APIs move. The protocol is the stable surface; the SDK APIs are not yet. @dreamlake/dreamdb changed shape substantially between 0.3 and 0.4, and will again before 1.0.

Where releases are recorded

Release notes and the implementation changelog track the protocol and reference implementation. Python package changes are recorded in the Python SDK changelog; the registry remains authoritative for published files and dates. The JavaScript history on this page is sourced from npm.