Docs/Get startedv0.0.1-preview

Release notes — 0.0.1-preview

What TulaDB 0.0.1-preview contains, component by component; how it was tested; what it is not compatible with; and the issues known at release.

On this page
  1. What’s in it
  2. The engine
  3. Compatibility
  4. How it was tested
  5. Known issues
  6. Not in this release

0.0.1-preview, released 3 November 2026, is TulaDB’s first release: a developer preview for evaluation, integration testing and architecture review under the evaluation grant. It is pre-1.0 and not certified for production financial workloads. Every component below is a signed download on Downloads.

What’s in it

Download Version What it is Platforms
core 0.0.1-preview tuladb-installer: the server tuladbd, tulactl, tuladb_backup, tuladb_upgrade, tuladb_verify_store and the Prometheus exporter, in one static binary per platform Linux x86_64 and arm64 (Ubuntu 22.04/24.04, Debian 12, RHEL 9); macOS on Apple silicon for development
sdk 0.0.1-preview (Python wheel 0.0.1.dev0) client SDKs for Python, Java, Go, Rust and C, as files: no package registry is used Python 3.9+, Java 21+, Go 1.21+, Rust; a prebuilt C library for Linux x86_64, C source for the rest
dashboard 0.0.1-preview (wheel 0.0.1rc0) the operator console, as an offline bundle with its installer Linux x86_64 and arm64, Python 3.12
exporter 0.0.1-preview (wheel 0.0.1rc0) the Iceberg exporter, with offline wheelhouses per extra, Python and architecture glibc Linux x86_64 and arm64, CPython 3.11 and 3.12
prometheus-exporter 0.0.1-preview the Prometheus exporter on its own release line (the server installer already carries it) Linux x86_64 and arm64, macOS on Apple silicon
grafana-dashboards 0.0.1-preview six Grafana dashboards with their provisioning files any Grafana with a Prometheus datasource
eval 0.0.1-preview the developer quick setup: the TulaDB container images, the Compose stack with eval.sh, a Postman collection, the Helm chart and the observability bundle Docker or Podman on Linux x86_64 and arm64, or macOS on Apple silicon

Each download is signed keylessly (Sigstore) by its own release workflow at its release tag, and every directory carries trusted_root.json so the signature can be checked offline. The release jobs verify what downloads.tuladb.com serves — the signature, every hash and the manifest — before a release appears on Downloads.

The engine

  • One write path. Every write is a batch, up to 1,024 operations; a single operation is a batch of one. Writes and reads use separate ports, 7700 and 7800, so queries never block writes.
  • The ledger contract. Atomic double-entry transfers; two-phase holds with expiry; limits enforced on every posting; idempotent retries keyed by (source_id, ledger_id, currency, txn_id) and durable across restarts; rejected outcomes as queryable records.
  • Durable before acknowledged. On a cluster, an acknowledgement waits for fsynced copies on a majority of voters. The write-ahead log uses io_uring where the kernel allows it (see io_uring).
  • Replication. Raft-style consensus with follower proxying, quorum-gated durability and full-copy node joins (Replication, Adding a node).
  • Security on by default for a cluster. Mutual TLS on every port, certificate principals with role grants, API keys; the riskiest misconfigurations refuse to start (Security, Self-protection).
  • History retention and export. Committed history streams to Apache Iceberg through the exporter, which holds an export lease so the WAL it still needs is never reclaimed (Analytics export).
  • Autotune. The shipped profiles let a node size a few settings from the machine it runs on, and never override a value you set (Autotune).

Compatibility

  • Wire version 4 only. Records are 384 bytes. The engine refuses any other wire version and every 0.0.1-preview SDK speaks 4, so an SDK or a node from an earlier development build fails with one clear refusal rather than misreading data.
  • On-disk formats are this release’s only. A data directory written by a development build before 0.0.1-preview is refused at start-up, naming the file and its format. Recreate it; there is no in-place conversion from development builds.
  • Upgrades from here on go through the new version’s tuladb-installer upgrade, one node at a time. It checks that the new build runs and opens the data in place before it switches, and puts the previous build back if the switch fails before the new one starts (Upgrade).

How it was tested

  • The release chaos gate passed on the release build. On 3 November 2026, core 2b2f8b96 ran for 75 minutes under the full fault schedule at 50,001 transfers per second offered, on three Arm nodes in Google Cloud with the Iceberg exporter on, and scored CHAOS_CLEAN=YES: money conserved, every replica in agreement, every leader loss under one second of unavailability, steady-state p99 7.3 ms. The verdict is on Chaos and soak testing.
  • The six-hour multi-region soak has not run yet. It is the second release criterion. Its verdict will be published on the same page, whatever it says.
  • Every component’s release job builds it, runs its test suite and smoke-tests the built files before anything is signed: the server packages in a clean container of every supported Linux distribution, on the target architecture, the dashboard and Iceberg exporter bundles by installing them offline on a clean host of each architecture, and the Grafana dashboards by checking every metric they query against the Prometheus exporter.

Known issues

  • The installer refuses hosts where systemd is installed but not running — containers and WSL, for example. systemctl answers “Failed to connect to bus” and the installer reports a service it cannot inspect. Install on a host booted with systemd, or use the developer quick setup, whose images are built without a running systemd.
  • Multi-region write latency. With one voter in each of three Google Cloud regions, diagnostic runs at 50K TPS measured steady-state write p99 in the hundreds of milliseconds (491 ms in the run of 2 November), against a 170 ms target for that shape. The cause has been traced to the replication path and is being worked on. Single-region clusters are unaffected: the release gate above measured p99 7.3 ms.
  • The REST gateway sometimes answers 503. In the evaluation stack, about one write in twelve returned 503 “could not refresh cluster topology” from the Python SDK server. The API contract marks 503 as retryable, and the Postman collection retries it; retry the same request, which is idempotent.
  • The dashboard backend ignores SIGTERM under Podman, so eval.sh down and purge wait the 10-second stop timeout before it is killed. No data is lost: the dashboard holds no ledger state.
  • RHEL 9 disables io_uring by default (kernel.io_uring_disabled=2), so the WAL falls back to fdatasync there. See io_uring on RHEL 9.
  • SDK scope. Go and Rust have no connection pool or leader-aware routing; their auto-batching BufferedLedgerClient arrives in the next SDK release. The C SDK is a starter, prebuilt for Linux x86_64 only.

Not in this release

  • No package-registry or container-registry publication: SDKs, bundles and images are files on Downloads.
  • No alert-rule download; the rule set described in Observability is available to design partners on request.
  • No software bill of materials, no SOC 2, PCI DSS or ISO 27001 report, and no third-party penetration test yet (Trust).
  • No rail adapters (the engine does not parse ISO 20022), and no liquidity alerts, forecasting, sweeps or payment queueing. See Problems solved for what ships today and what doesn’t.

Found something else? Report vulnerabilities as the disclosure policy describes, and everything else to [email protected].