KoutenDB v0.9.0

KoutenDB v0.9.0

KoutenDB v0.9.0 is a locality and validation release. It adds a more realistic
related-data read benchmark, improves bounded stellar/subring reads, and records
the large local validation results that drove the storage-path changes.

Release:

https://github.com/puffball1567/koutendb/releases/tag/v0.9.0

What Changed

• Added examples/subring_bundle_bench.nim.
• Added examples/subring_bundle_postgres_bench.sh.
• Added per-subring limit and sort validation for stellar reads.
• Optimized readStellar by preparing projection state once and reusing it
  across subrings.
• Added a bounded ring-window read path for simple embedded reads with empty
  filters, positive limits, and id or time sorting.
• Added cached disk segment read streams for disk-backed segment reads.
• Updated benchmark documentation with the latest local PostgreSQL and
  KoutenDB related-data bundle comparison.
• Updated effect-validation documentation with the completed 13.5M-record local
  stress result.

Why This Matters

This release focuses on a practical shape that appears in ordinary
applications: a detail endpoint that needs a root entity plus several related
collections, where each collection has its own limit and sort order.

In KoutenDB this can be expressed as nearby subrings:

kouten get --ring=users/<id> \
  --subring=profile,addresses,career,preferences,orders,notifications \
  --subring-limit=profile:1,addresses:3,career:2,preferences:1,orders:10,notifications:5 \
  --subring-rsort=orders:time,notifications:time

The goal is not to claim that KoutenDB is universally faster than PostgreSQL or
Redis. The goal is narrower and more important for KoutenDB's design: when the
application already has useful locality, KoutenDB should retrieve the nearby
working set directly, without turning the request into a broad scan or a
response-shaping query.

Local Benchmark Result

Measured on 2026-07-21 with AMD Ryzen 5 5600H, Linux 6.8, Nim 2.2.10, and
PostgreSQL 14.23. The helper creates fresh temporary KoutenDB and PostgreSQL
data directories.

Reproduce:

N=10000 READS=1000 examples/subring_bundle_postgres_bench.sh

Result:

Users	Logical records	Group	Query shape	Returned records	read latency us
10,000	1,050,000	KoutenDB	users/<id>/* stellar read with per-subring limits/sorts	22 across 6 rings	196.859
10,000	1,050,000	PostgreSQL 14.23	six indexed SELECT statements	22	515
10,000	1,050,000	PostgreSQL 14.23	one JSON aggregate query over indexed limited subqueries	1 JSON bundle	236

This is a specific related-data bundle workload, not a universal PostgreSQL
claim. PostgreSQL can express the result with indexed limited subqueries and
JSON aggregation, but the query shape is no longer a plain join. KoutenDB
expresses the access pattern as bounded nearby subrings.

Large Effect Validation

The generated scale-1000 effect-validation path also completed locally with
13,500,000 documents in the largest standard case. The measured result is
documented in docs/effect-validation.md.

Summary:

• small-balanced: 168000 -> 24000 scanned records, 692 -> 260 estimated
  tokens.
• near-distractors: 1860000 -> 120000 scanned records, 1730 -> 433
  estimated tokens.
• medium-noisy: 13500000 -> 500000 scanned records, 2595 -> 692
  estimated tokens.

The largest case also exposed a useful follow-up target: post-import segment
packing is much faster than the earlier unbuffered path, but still large enough
to keep optimizing.

Verification

This release state was verified with:

• nim check src/kouten/store.nim
• nim check src/koutendb.nim
• nim check src/koutencli.nim
• nim check tests/tapi.nim
• nim c --nimcache:/tmp/nimcache_kouten_tapi -r tests/tapi.nim
• scripts/test_all_smoke.sh
• nimble check
• git diff --check

The large generated benchmark is intentionally manual and is not part of the
default CI smoke suite.

KoutenDB v0.8.0

KoutenDB v0.8.0

KoutenDB v0.8.0 is a naming and migration release.

Release:

https://github.com/puffball1567/koutendb/releases/tag/v0.8.0

The project was previously published under older names. The active project name
is now KoutenDB. The package name, CLI name, daemon name, C ABI names, repository
links, documentation, examples, and driver-facing references have been moved to
the KoutenDB naming scheme.

Why KoutenDB

Kouten comes from the Japanese word "kouten" (公転), meaning orbital
revolution: one body moving around another.

That meaning fits the database model. KoutenDB uses ring and orbit-inspired
placement as part of the retrieval path. A record is not only stored somewhere;
its placement is meant to help decide what should be read together later. The
goal is to reduce unrelated reads, transferred bytes, candidate memory, and
downstream AI/RAG or application work when the application has meaningful
locality.

The name therefore describes the technical direction more directly:

• rings and orbit-inspired coordinates are part of the data model
• locality is exposed to the database instead of reconstructed after each query
• retrieval starts from meaningful placement rather than from a global scan
• the project remains focused on smaller working sets, not on scanning the
  entire corpus faster

What Changed

• Public project name: KoutenDB
• Nim package: koutendb
• CLI: kouten
• Daemon: koutend
• C ABI library: libkoutendb.so
• C header: include/koutendb.h
• C ABI symbol prefix: kouten_*
• C ABI constants and environment variables: KOUTEN_* / KOUTENDB_*
• Main repository URL: https://github.com/puffball1567/koutendb

The technical direction is unchanged. KoutenDB remains a ring-oriented
NoSQL/document/vector store for locality-aware retrieval and smaller working
sets.

Migration Notes

New installations should use:

nimble install koutendb
kouten --help

From source:

git clone https://github.com/puffball1567/koutendb.git
cd koutendb
nimble check
scripts/test_all_smoke.sh

C ABI users should build through the canonical script:

scripts/build_capi.sh

and link against:

include/koutendb.h
lib/libkoutendb.so

External drivers should move to the KoutenDB package and repository names. Older
names may still appear in historical posts or archived package entries, but the
active project name is KoutenDB.

Verification

The rename branch was verified with:

• nim check src/koutendb.nim
• nim check src/koutencli.nim
• nim check src/koutend.nim
• nim check src/koutendb_capi.nim
• nimble check
• scripts/build_capi.sh
• scripts/test_core.sh
• scripts/cli_crud_smoke.sh
• scripts/cabi_tls_smoke.sh
• scripts/driver_compat.sh
• scripts/test_all_smoke.sh

GitHub Actions for the rename PR also passed, including the Linux and macOS C
ABI checks.

Known Boundaries

• KoutenDB remains a technical preview / research OSS.
• This release is primarily a naming and migration release, not a new storage
  engine feature release.
• External driver packages may need their own coordinated KoutenDB-name
  releases.
• Historical articles, forum posts, and package names may still mention older
  names during the transition.

RocheDB v0.7.0

RocheDB v0.7.0

RocheDB v0.7.0 is a technical-preview release focused on hardening the storage,
wire, C ABI, TLS, and universe-sync paths while keeping RocheDB's scope honest:
it is still not presented as a production replacement for Redis, PostgreSQL,
MongoDB, Apache Arrow, or dedicated vector databases.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.7.0

The main goal of this release is to reduce the number of silent-failure paths
around persistence, driver-facing builds, sync acknowledgements, and operational
misconfiguration. It also expands the runnable demo and smoke matrix so
RocheDB's locality model can be checked with more than happy-path examples.

Main Changes

• Added scripts/build_capi.sh as the canonical C ABI shared-library build
  path. It builds with --app:lib -d:ssl -d:release.
• Updated driver installation docs and compatibility scripts to use the
  canonical C ABI build path.
• Added C ABI TLS smoke coverage.
• Added Linux and macOS CI coverage for the C ABI build path.
• Enabled --panics:on so internal Defects do not become false success values
  through C ABI calls.
• Added persistent data-directory locking to prevent two processes from
  opening the same store and corrupting transaction identity.
• Hardened universe sync acknowledgement handling, retry accounting,
  dead-letter handling, remote sync recovery, and idempotent replay.
• Added bounded applied-event dedup persistence for universe sync.
• Added server-side retrieve budget and scan guards for safer broad queries.
• Added lock fencing-token persistence for ring and stellar locks.
• Added docs/data-migration.md for JSONL dump/import as the main pre-v1
  compatibility boundary.
• Added docs/time-orbit.md for calculated time-bucket placement.
• Added scripts/demo_smoke.sh to exercise stellar, codec, and locality demos.
• Added cluster wire driver smoke coverage to the full smoke suite.

Why This Release Matters

RocheDB's main bet is that meaningful placement can reduce unnecessary reads,
transfers, memory pressure, and downstream AI/RAG work. v0.7.0 does not change
that thesis; it makes the implementation more trustworthy around the boring
parts that matter for databases:

• storage must fail closed when a directory is already open elsewhere
• C ABI callers must not see false success after internal Defects
• TLS-capable driver builds need one canonical command
• universe sync must not prune events unless the target actually accepted them
• broad reads need explicit limits and diagnostics
• demo and smoke scripts must keep proving that core workflows still run

Example: C ABI Build

scripts/build_capi.sh

The script writes the shared library to build/capi/ and is the recommended
path for Rust, JavaScript / TypeScript, PHP, C++, Swift, Kotlin, Go, and C#
driver work.

Example: Full Smoke

scripts/test_all_smoke.sh

The all-smoke suite now includes:

• core tests
• CLI CRUD smoke
• cluster transaction and failure recovery smoke
• authz / RBAC smoke
• driver wire-protocol smoke
• wire fuzz smoke
• TLS smoke
• recovery smoke
• universe sync failure and remote sync smoke
• demo smoke

Documentation

New and updated documents include:

• docs/audit-remediation.md
• docs/data-migration.md
• docs/time-orbit.md
• docs/driver-installation.md
• docs/protocol-compatibility.md
• docs/tls-transport.md
• docs/threat-model.md
• docs/query-safety.md
• docs/public-api.md
• docs/test-coverage.md
• docs/release-checklist.md
• docs/rochedb-status.md

Verification

The local release verification pass included:

• scripts/test_all_smoke.sh
• nimble check

scripts/test_all_smoke.sh includes the expanded cluster, TLS, recovery,
universe-sync, codec, stellar, and locality demo checks listed above.

Known Boundaries

• RocheDB remains a technical preview / research OSS.
• Online dynamic membership and live rebalance are still planned, not complete.
• Cluster transaction coordinator redundancy is still planned.
• Universe sync remains a durable eventual-convergence primitive, not a
  consensus or quorum system.
• JSONL dump/import is the recommended compatibility boundary before v1.0.
• External driver packages may lag the core C ABI surface and should be checked
  against their own package release notes.

RocheDB v0.6.0

RocheDB v0.6.0

RocheDB v0.6.0 is a technical-preview release focused on topology remapping
foundations, locality validation, and easier operational configuration.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.6.0

RocheDB is still not presented as a production replacement for Redis,
PostgreSQL, MongoDB, Apache Arrow, or a dedicated vector database. The stronger
claim in this release is narrower: RocheDB now has more measurable support for
preserving logical query results while exercising locality-oriented layouts,
and it has a clearer foundation for future topology changes.

Main Changes

• Added typed RocheFilterBuilder helpers for safer read filters without
  string-concatenated JSON.
• Added topology remapping primitives:
  • explicit arc tables
  • weighted arcs
  • deterministic virtual arcs
  • topology validation
  • remapFraction
• Added docs/topology-remapping.md to describe the boundary between remapping
  primitives and future online rebalance.
• Added locality validation workloads for random, delete-heavy, backfill-heavy,
  hot/cold, and interleaved write patterns.
• Added locality invariant checks: the same logical ring query must return the
  same ID/payload set before and after compaction while disk-span and candidate
  metrics are reported.
• Added CLI connection config loading with --config=FILE and ROCHE_CONFIG.
• Added docs/use-case-recipes.md with application recipes for list/detail,
  membership, inventory locks, webhook idempotency, SaaS tenant isolation,
  stellar neighborhoods, and RAG corpus layout.

Why This Release Matters

RocheDB's thesis is that meaningful placement should reduce unnecessary reads,
transfers, memory pressure, and downstream AI/RAG work. v0.6.0 strengthens the
engineering around that thesis in two ways.

First, locality is now easier to test as an invariant rather than only a
narrative. The demo workloads mutate, delete, backfill, compact, and re-read
the same logical rings, then report whether the result set stayed stable and
how the physical layout metrics changed.

Second, topology remapping now has explicit primitives. RocheDB still does not
perform online dynamic membership or live rebalance in this release, but the
core can model ownership with arc tables and compare remapping behavior without
falling back to naive mod nNodes reasoning.

Example

Connection config:

{
  "peers": ["127.0.0.1:17301"],
  "galaxy": "docs",
  "user": "alice",
  "password": "secret",
  "tls": {
    "enabled": true,
    "ca": "certs/ca.pem",
    "cert": "certs/client.pem",
    "key": "certs/client-key.pem"
  }
}

Use it from the CLI:

roche --config=roche.json health

ROCHE_CONFIG=roche.json roche put \
  --ring=docs/japan \
  --payload='{"title":"Hello","status":"draft"}' \
  --codec=json

ROCHE_CONFIG=roche.json roche get \
  --ring=docs/japan \
  --filter='{"status":"draft"}' \
  --selection='{ title status }'

Run locality validation:

examples/locality_layout_demo.sh

The demo prints invariant and layout metrics such as:

invariant ring=docs/topic/7 sameSet=true beforeCandidates=... afterCandidates=...

Documentation

New and updated documents:

• docs/topology-remapping.md
• docs/use-case-recipes.md
• docs/data-locality.md
• docs/config-reference.md
• docs/cli-reference.md
• docs/test-coverage.md
• docs/rochedb-status.md

Verification

The local verification pass included:

• nim check examples/locality_layout_demo.nim
• nim c -r --nimcache:/tmp/nimcache_roche_tstore tests/tstore.nim
• scripts/test_core.sh
• scripts/cli_crud_smoke.sh
• scripts/test_all_smoke.sh
• examples/locality_layout_demo.sh workloads for random, delete-heavy,
  backfill-heavy, hot/cold, and interleaved cases during the feature branch
  verification cycle
• git diff --check

Known Boundaries

• RocheDB remains a technical preview / research OSS.
• Online dynamic membership and live rebalance are still planned, not complete.
• Cluster transaction coordinator redundancy is still planned.
• Universe sync remains a durable eventual-convergence primitive, not a
  consensus or quorum system.
• The next hardening track should focus on the audit items around C ABI failure
  handling, crash-safe compact/backup/restore, WAL integrity, sync ack safety,
  data-directory locking, and server resource limits.

RocheDB v0.5.1

RocheDB v0.5.1

RocheDB v0.5.1 is a documentation-focused patch release for the v0.5.x
technical preview.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.5.1

Main Changes

• Added docs/technical-faq.md.
• Linked the Technical FAQ from README.md.
• Linked the Technical FAQ from the documentation index.

Why This Patch Exists

RocheDB has enough unusual terminology that first-time reviewers need a direct
technical entry point. The new FAQ answers the questions most likely to come
from database engineers:

• Is a ring just partitioning?
• Is stellar locality a join?
• Is this a secondary index?
• Is the orbital model just consistent hashing?
• Where do the benchmark improvements come from?
• How are records grouped on disk?
• What happens when write patterns are messy?
• Is RocheDB production-ready?

The answers are intentionally conservative. They explain RocheDB's current
strengths, but also document boundaries around production readiness, dynamic
membership, broad secondary-index planning, and real-workload validation.

Verification

This release contains documentation and package metadata changes only.

Verified with:

• git diff --check
• GitHub Actions on the documentation PR into devel

Known Boundaries

The v0.5.0 implementation boundaries remain unchanged:

• dynamic cluster membership with minimal remapping is still planned;
• longer mixed-version protocol compatibility is still planned;
• deeper failure-injection tests are still planned;
• broader driver parity is still in progress.

RocheDB v0.5.0

RocheDB v0.5.0

RocheDB v0.5.0 is a technical-preview release focused on making RocheDB's
placement-aware data model more explicit and more useful for ordinary
application workflows.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.5.0

RocheDB is still not presented as a production replacement for Redis,
PostgreSQL, MongoDB, Apache Arrow, or a dedicated vector database. The stronger
claim in this release is narrower: RocheDB can make meaningful data placement
part of the read path, operating boundary, and high-integrity application
workflow.

Main Changes

• Added stellar locality lens workflows.
• Added roche get --stellar=... with --subring, filter, selection, and
  grouped output.
• Added roche stellar attach|detach|list.
• Added non-copy visibility metadata for existing rings.
• Added embedded atomic bulk helpers:
  • batchPutAtomic
  • batchUpdateAtomic
  • batchDeleteAtomic
• Added opt-in embedded cooperative coordinate locks:
  • acquireRingLock
  • acquireStellarLock
  • withRingLock
  • withStellarLock
  • releaseLock
  • lockActive
• Added docs/unique-data-model.md.
• Added examples/stellar_data_model_demo.sh.
• Updated benchmark comparison tables and benchmark notes with the latest local
  and Docker-Docker measurements.

Why This Release Matters

RocheDB's model is no longer only "place records in rings and retrieve from
rings". This release adds a clearer shape for application data:

ring     = meaningful coordinate
stellar  = locality lens over related coordinates
subring  = narrowed field of view
lock     = opt-in coordination around a coordinate or lens
atomic   = all-or-nothing embedded bulk workflow

This makes RocheDB more useful for ordinary application domains such as SaaS,
CRM, support tools, catalogs, user/order detail views, and AI/RAG knowledge
systems. It does not turn RocheDB into a payment ledger or a financial core
database, but it gives application workflows stronger primitives around
external payment systems, retries, webhooks, and coordinated updates.

Example

roche put --ring=users/123 \
  --payload='{"kind":"user","name":"Alice"}' --codec=json

roche put --ring=shops/1123 \
  --payload='{"kind":"shop","name":"Orbit Store"}' --codec=json

roche put --ring=orders/A-001 \
  --payload='{"kind":"order","orderNo":"A-001","total":42}' --codec=json

roche stellar attach --stellar=commerce/order/A-001 --ring=users/123
roche stellar attach --stellar=commerce/order/A-001 --ring=shops/1123
roche stellar attach --stellar=commerce/order/A-001 --ring=orders/A-001

roche get --stellar=commerce/order/A-001 \
  --selection='{ kind name orderNo total }'

roche get --stellar=commerce/order/A-001 --subring=shops

Benchmark Notes

The benchmark documents were updated with the latest local verification pass.
The headline working-set results remain stable:

• Working-set benchmark: scanned/query 10000 -> 100.
• Memory-pressure benchmark: candidate memory/query 46.539 MiB -> 0.465 MiB
  in the light verification run.
• Synthetic RAG benchmark: recall stayed 1.000 while scanned/query dropped
  8000 -> 1000 and estimated tokens/query dropped 3955 -> 657.
• Local Redis comparison: RocheDB single TCP GET remains in the same latency
  class as Redis GET, while RocheDB batch get remains faster than Redis
  pipeline GET in the local helper run.

These are local benchmark results, not universal performance claims. The point
is that the reduced working set is not being bought with an obviously slow
local read path.

Verification

The local verification pass included:

• nim check src/rochedb.nim
• nim check src/rochecli.nim
• scripts/test_core.sh
• scripts/cli_crud_smoke.sh
• working-set, memory-pressure, RAG, Redis, PostgreSQL, and Docker-Docker
  comparison helpers during the feature branch verification cycle
• git diff --check

Known Boundaries

• Cluster transaction coordinator redundancy is still planned.
• Dynamic membership / arc-table based remapping is still planned.
• Cooperative locks are embedded opt-in workflow guards in this release; normal
  put, get, list, and retrieve paths do not check them.
• RocheDB is not a payment ledger or a financial-core database.

RocheDB v0.4.1

RocheDB v0.4.1

RocheDB v0.4.1 is a documentation and process patch release.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.4.1

Main Changes

• Added docs/development-workflow.md.
• Documented the stable-main / devel integration workflow.
• Clarified branch roles for:
  • main
  • devel
  • feature/...
  • docs/...
  • test/...
  • release/vX.Y.Z
  • hotfix/...
• Linked the workflow from CONTRIBUTING.md.
• Linked the workflow from the documentation index.

Branch Policy Summary

• main is the released, tagged, public-stable branch.
• devel is the integration branch for the next release.
• Normal feature, test, and documentation work targets devel.
• Release branches are cut from devel and merged into main.
• Tags are created only from main.

Verification

The documentation workflow PR passed the repository CI before merge into
devel:

• Nim checks and C ABI
• Core test suite
• CLI, cluster, recovery, and universe smoke
• TLS transport smoke

RocheDB v0.4.0

RocheDB v0.4.0

RocheDB v0.4.0 adds TLS transport support and repository-level CI coverage.

Release:

https://github.com/puffball1567/rochedb/releases/tag/v0.4.0

Main Changes

• Added optional TLS transport for roched, RocheDB Nim clients, CLI commands,
  and the C ABI.
• Added roche_connect_auth_tls as an additive C ABI entry point.
• Added TLS CLI flags:
  • --tls
  • --tls-ca=FILE
  • --tls-server-name=NAME
  • --tls-insecure-skip-verify
• Added TLS server flags:
  • --tls-cert=FILE
  • --tls-key=FILE
  • --tls-ca=FILE
  • --tls-server-name=NAME
  • --tls-insecure-skip-verify
• Added docs/tls-transport.md.
• Added a TLS smoke test that verifies:
  • TLS health check;
  • authenticated JSON put/get over TLS;
  • plain clients are rejected by a TLS listener.
• Added GitHub Actions CI for:
  • Nim semantic checks;
  • SSL-enabled semantic checks;
  • C ABI contract coverage;
  • core tests;
  • CLI, cluster, recovery, and universe smoke tests;
  • TLS transport smoke tests.

Build Note

TLS support requires building RocheDB with Nim's SSL support:

nim c -d:ssl -d:release -o:bin/roched src/roched.nim
nim c -d:ssl -d:release -o:bin/roche src/rochecli.nim

Without -d:ssl, non-TLS operation remains available.

Verification

Before release, the following checks passed locally or in GitHub Actions:

• nim check src/rochedb.nim
• nim check src/rochecli.nim
• nim check src/roched.nim
• nim check src/rochedb_capi.nim
• nim check -d:ssl src/rochecli.nim
• nim check -d:ssl src/roched.nim
• nim check -d:ssl src/rochedb_capi.nim
• C ABI contract test
• scripts/cluster_tls_smoke.sh
• scripts/test_all_smoke.sh
• GitHub Actions CI jobs added in this release

RocheDB v0.3.0 Technical Preview

RocheDB v0.3.0 Technical Preview

RocheDB v0.3.0 expands the driver-facing and codec-aware read surface. The
notable change is C ABI v2 with roche_read_ring_json, which gives external
drivers a stable ring-read page shape similar to the CLI roche get --ring=...
workflow.

This is still a technical preview / research OSS release. Do not present it as
a production replacement for Redis, PostgreSQL, MongoDB, Apache Arrow, or a
mature vector database. The defensible claim remains narrower: RocheDB can
reduce working-set size and downstream retrieval input when data is placed in
meaningful rings, while the implementation is gaining the operational checks
needed for broader evaluation.

Highlights

• C ABI v2 with roche_read_ring_json for JSON filters, optional projection,
  cursor/page reads, sorting, codec metadata, and stable page-shaped JSON
  responses.
• Unified ring-oriented CLI read behavior around one result shape for one or
  many records.
• Explicit CLI and documentation paths for JSON, NIF, BIF, raw, and
  ring-profile --codec=auto payload workflows.
• Expanded C ABI contract smoke coverage for JSON projection, NIF/BIF metadata,
  invalid filters, invalid sort fields, and null-ring errors.
• Expanded embedded API coverage for readRing filtering, pagination, sorting,
  defaulting, and codec-aware projection rejection.
• Expanded CLI smoke coverage for codec display, BIF base64/hex/adapter views,
  invalid filters, invalid sort fields, invalid projection requests, shell, and
  user-facing auth errors.
• Added docs/test-coverage.md to make the release validation matrix explicit.

Validation Run

The v0.3.0 pre-release verification pass included:

• scripts/test_core.sh
• scripts/cli_crud_smoke.sh
• scripts/test_all_smoke.sh
• C ABI shared-library build
• gcc examples/cabi_contract.c ...
• LD_LIBRARY_PATH=lib bin/cabi_contract
• nimble check
• git diff --check

scripts/test_all_smoke.sh covers core tests, CLI CRUD, cluster transactions,
cluster failure, authz/RBAC, wire fuzz, recovery, universe sync failure, and
remote universe sync. Driver compatibility remains optional through
ROCHE_TEST_DRIVERS=1.

Known Gaps

• TLS is not implemented; do not expose roched directly on untrusted
  networks.
• Cluster membership is static.
• node0 remains the cluster transaction landing coordinator.
• Cluster coordinator redundancy, dynamic membership, and epoch migration are
  not implemented.
• Universe sync is durable eventual sync, not immediate global serializability.
• Long-running cluster soak, mixed-version protocol, larger universe backlog,
  and multi-environment validation are expected to grow through external
  evaluation and reports.

Links

• README: README.md
• Test coverage: docs/test-coverage.md
• Status / roadmap: docs/rochedb-status.md
• Public API: docs/public-api.md
• Configuration reference: docs/config-reference.md
• CLI reference: docs/cli-reference.md
• Payload codecs: docs/payload-codecs.md
• Universe sync: docs/universe-sync.md
• Topology examples: docs/topology-examples.md
• Benchmarks: docs/rochedb-bench.md
• Release checklist: docs/release-checklist.md
• Driver installation guide: docs/driver-installation.md
• Threat model: docs/threat-model.md
• Third-party notices: THIRD_PARTY_NOTICES.md

RocheDB v0.2.5

Summary

• Restores the ordinary cluster GET/BGET read path after transaction landing-zone support added an extra request on normal reads.
• Keeps read-your-writes behavior for accepted-but-not-yet-applied cluster writes by tracking pending IDs on the current client.
• Fixes benchmark stable-ring selection so full-period orbits are not treated as stable during cluster latency runs.
• Updates PostgreSQL and Redis benchmark documentation with the 2026-07-08 local retest results.
• Adds comparison-friendly benchmark tables at docs/benchmark-comparison.md.

Verification

• scripts/test_core.sh
• scripts/cluster_tx_smoke.sh