Skip to main content

Versioned key-record store over a content-addressed bytes store (memory or Ethereum Swarm/Bee backends)

Project description

recordstore

A versioned key→record store over a content-addressed bytes store — a thin database kernel between an immutable blob store (such as Ethereum Swarm) and an application that wants to think in records and versions rather than blobs and references.

from recordstore import RecordStore, MemoryBytesStore

blobs = MemoryBytesStore()
store = RecordStore(blobs)
store.put("users/alice", {"name": "Alice", "role": "admin"})
store.put("users/bob", {"name": "Bob"})
root = store.commit()          # one reference identifies this entire version

store.get("users/alice")       # {'name': 'Alice', 'role': 'admin'}
list(store.keys("users/"))     # ['users/alice', 'users/bob']

snapshot = RecordStore.at(root, blobs)   # frozen view of that version

Concurrent writers converge without a lock server — if the shared pointer moved under a commit, it three-way merges and retries:

from recordstore import MemoryPointer

pointer = MemoryPointer(root)                  # a shared "latest version" name
a = RecordStore(blobs, pointer=pointer)        # two writers open the same version
b = RecordStore(blobs, pointer=pointer)
a.put("users/carol", {"name": "Carol"}); a.commit(reconcile=True)
b.put("users/dave",  {"name": "Dave"});  b.commit(reconcile=True)   # folds in a's change
# the pointer now names a version containing both carol and dave

Why

Content-addressed stores give you immutable put(bytes) → ref / get(ref) → bytes and nothing else: no keys, no typed records, no transactions, no snapshots. recordstore adds exactly that missing layer and nothing more:

  • Records instead of raw bytes — values are any JSON-compatible object, stored under string keys.
  • Atomic, versioned commits — mutations are staged in memory; commit() lands all of them as one new root reference. A reader either sees all of a commit or none of it.
  • Snapshot isolationRecordStore.at(root, blobs) pins one root and sees a frozen, self-consistent dataset for arbitrarily long reads, with no locking: the whole dataset-at-a-version is one reference.
  • Canonical roots — encodings are deterministic, so equal content produces an equal root reference, regardless of the insertion/deletion history that produced it. Versions are content-addressable, comparable with a string equality check, and cheap to diff.
  • Three-way mergeRecordStore.merge(base, ours, theirs) reconciles two divergent versions; canonicity makes unchanged subtrees merge for free and equal edits conflict-free, with conflicts raised or settled by a resolver(key, base, ours, theirs) you supply. The diff is O(divergence), not O(dataset).
  • Multi-writer, no lock servercommit(reconcile=True) makes concurrent writers converge: if the pointer moved under you it three-way merges and retries instead of overwriting. Race-free in-process; best-effort across processes over a Swarm feed. A commutative resolver keeps 3+ writers order-independent.
  • Structural sharing — versions are stored as a persistent (copy-on-write) compacted radix trie; a commit writes only the blobs along the changed paths, and unchanged subtrees are shared between versions.
  • Concurrent I/Oitems() (bulk read), get_many/put_many, and a pooled keep-alive HTTP session let BeeBytesStore parallelise round trips instead of paying one per record — the difference between usable and not on a high-latency link.

Install

pip install recordstore

# with the Bee (Swarm) bytes backend's HTTP dependency:
pip install "recordstore[bee]"

# with the Swarm feed pointer (adds swarm-bee for SOC/secp256k1 signing):
pip install "recordstore[feeds]"

Python ≥ 3.9. The core imports only the standard library; both extra dependencies are imported lazily — requests only by BeeBytesStore ([bee]), swarm-bee only by SwarmFeedPointer ([feeds]).

The pieces

Layer What it does Implementations
BytesStore put(bytes) → ref, get(ref) → bytes MemoryBytesStore (in-memory, testing), DirBytesStore (durable local directory), FsspecBytesStore (S3/GCS/HTTP/… via fsspec), BeeBytesStore (Swarm Bee node over /bytes — the blob endpoint, not the raw /chunks/{address} primitive)
trie (internal) canonical persistent radix trie mapping keys to value blobs
RecordStore staging, commit() / commit(reconcile=True), snapshots, sorted keys()/items(), three-way merge()
Pointer mutable name for the latest root MemoryPointer, FilePointer (atomic local file), SwarmFeedPointer (owner-signed Swarm feed, over swarm-bee)

| swarm_store(topic, ...) | assembles the two Swarm pieces into a store | the one place Swarm is chosen: BeeBytesStore blobs and a SwarmFeedPointer head |

Nothing above RecordStore ever sees a stored blob or a trie node — and nothing below it needs to know Swarm exists unless you asked for it:

from recordstore import swarm_store

store = swarm_store("my-notes", signer=key)   # publish: blobs + feed on Swarm
store = swarm_store("my-notes", owner=addr)   # follow someone else's feed

Documentation

  • User guide — concepts, full API, the canonicity contract, running against a real Bee node, versioning patterns, error handling, and current limitations.

Testing

python3 -m pytest tests/                                 # unit + fuzz + boundary tests

BEE_API=http://<node>:1633 BEE_BATCH=<batchID> \
    python3 -m pytest tests/test_recordstore_bee.py -v   # bytes backend, live node

pip install "recordstore[feeds]"                         # needs swarm-bee
BEE_API=http://<node>:1633 BEE_BATCH=<batchID> \
    python3 -m pytest tests/test_recordstore_feed.py -v  # feed pointer, live node

The fuzz suite runs randomized put/delete histories against a plain-dict oracle and asserts the canonical-root property throughout. The Bee integration tests skip automatically unless BEE_API is set (the feed test also needs swarm-bee installed); against a real (non-dev) node always provide BEE_BATCH with a purchased postage batch id.

Background

This is a Python re-implementation of an old idea — content-addressed, canonical-root, versioned key-value storage — best known from Ethereum's Merkle Patricia Trie and from Noms/Dolt's "prolly trees." The value here is fit, not novelty: a much simpler canonical encoding than MPT (avoiding the exact bug class that once caused a chain split), a far smaller scope than Dolt/Irmin (no query language; a single three-way merge primitive, not a merge engine), and — as far as we could find — the first implementation of this pattern for Python with a Swarm/Bee backend. See the user guide's background section for the full comparison.

Status

Extracted from petfold/ontodag (July 2026) with history preserved; validated against a live Bee 2.8.1 light node on Gnosis mainnet (roundtrips, canonical roots on real BMT references, network retrievability). SwarmFeedPointer (owner-signed Swarm feed, over swarm-bee) landed in v0.4.0; three-way merge in v0.8.0; auto-reconciling commit(reconcile=True) in v0.9.0; a best-effort feed compare_and_set (cross-process reconcile) in v0.10.0. Known gaps — a Swarm feed has no atomic index claim, so exactly-simultaneous same-index writes can still race (in-process reconcile is race-free); one blob per record — are detailed in the user guide.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

recordstore-0.13.1.tar.gz (40.1 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

recordstore-0.13.1-py3-none-any.whl (24.4 kB view details)

Uploaded Python 3

File details

Details for the file recordstore-0.13.1.tar.gz.

File metadata

  • Download URL: recordstore-0.13.1.tar.gz
  • Upload date:
  • Size: 40.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.14

File hashes

Hashes for recordstore-0.13.1.tar.gz
Algorithm Hash digest
SHA256 bb816065f0f9559bed420aaefbac4c753531d14d15fff1dbc6c40bbc0c859773
MD5 b691e2e8db8df4e980a1dfedc850ef67
BLAKE2b-256 5fceb41acb90ac59bd291d5f3b3d59474aa052b99983e13939b955c0fef3985d

See more details on using hashes here.

Provenance

The following attestation bundles were made for recordstore-0.13.1.tar.gz:

Publisher: release.yml on petfold/recordstore

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file recordstore-0.13.1-py3-none-any.whl.

File metadata

  • Download URL: recordstore-0.13.1-py3-none-any.whl
  • Upload date:
  • Size: 24.4 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.14

File hashes

Hashes for recordstore-0.13.1-py3-none-any.whl
Algorithm Hash digest
SHA256 766c9b6324884a287bef6016b4c57ab7c8ae1a9b105ac817cdbb56fa32dc848a
MD5 e98fa9621e169bd7e9f1dd62d97c139d
BLAKE2b-256 c8f38f191e18ea8228a35a97e4321cdc4f0fb751d58d98a7b0c0c8984c5cdaf3

See more details on using hashes here.

Provenance

The following attestation bundles were made for recordstore-0.13.1-py3-none-any.whl:

Publisher: release.yml on petfold/recordstore

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page