Path to production

This page answers the questions a production evaluation asks, in the order a review board asks them — including the ones where the honest answer is “not yet.” TulaDB is in developer preview; the fastest way to a bad outcome is a docs page that pretends otherwise.

What 0.0.1-preview is

0.0.1-preview is the first release. It is suitable for evaluation, benchmarking, integration testing and architecture review. It is not certified for production financial workloads, and a production deployment needs its own hardening, security review, operational drills and workload-specific validation. A pilot runs on replayed or anonymised copies of your own traffic, in a non-production environment, under the evaluation licence.

What stands behind it today is the engine’s full local test suite, the deterministic simulators, and fault-injected chaos runs and multi-hour soaks on three-node clusters, gated on exact money conservation and replica agreement — run against development builds leading up to this release. On the 0.0.1-preview build itself, the 50K TPS release chaos gate passed on 3 November 2026; the six-hour multi-region soak has not run yet, and we make no claim for it until it has. No multi-day soak result is claimed. The release criteria, and every recorded development run with its verdict as written, are on Chaos and soak testing.

Distribution is a preview distribution: every component is a signed download on Downloads — the server through tuladb-installer, the SDKs as files, the dashboard and the Iceberg exporter as offline bundles, the container images for the developer quick setup as docker load tarballs — and nothing is published to PyPI, Maven Central, crates.io or a container registry yet.

Data-loss and recovery objectives

Acknowledged writes: designed for zero data loss in a cluster. An acknowledgement is issued only after the write is durable in the WAL and held by a quorum of voters — so a leader crash, node loss, or single-AZ loss does not lose acknowledged writes. On a single node, the same WAL-before-ack rule applies unless you explicitly enable async_flush, which trades a loss window for throughput and requires an explicit acknowledgement of that trade (allow_single_node_async_ack_loss) to even run. That window is real and measured: in a modelled machine-loss test (2026-10-26) the durable default lost none of 37,392 acknowledged transfers, while the async opt-in lost 0.8–1.4% of its acknowledgements — everything acknowledged since the last background sync. On a single node, treat it as benchmark-only. In a cluster, async_flush only takes the fsync off the leader’s critical path: an acknowledgement still waits for fsynced copies on a majority of voters, so the loss window does not apply (details).

Recovery time: bounded by design, measured by you. Restart replays only the WAL tail since the last snapshot — O(tail), not O(history) — and failover is a Raft election (sub-second timeouts by default) plus catch-up. We do not publish an RTO number, deliberately: recovery time depends on your snapshot cadence, WAL tail size, hardware, and dataset, and a number measured on ours would mislead you on yours. What we provide instead is the machinery to measure it: restore drills as a first-class tool feature, the fault schedule from the chaos campaigns, and readiness signals (tulactl ready, or node_ready in runtime/metrics.json inside the engine image, which has no tulactl) that make “recovered” a checkable state rather than a feeling. A production sign-off should include your own timed kill/restore drills on your own topology — we’ll help design them in a pilot.

Region loss. The reference topology is one region, three availability zones — it survives an AZ loss with no data loss and no failover scripting. For loss of the whole region, the supported recovery is backup plus archived WAL: restore to an exact committed position in a new region. Synchronous multi-region quorum is not the recommended posture today; if your requirements demand it, bring that to a design-partner conversation rather than assuming it.

Upgrades

From development builds: none. 0.0.1-preview makes no compatibility promise to the development builds before it. The wire protocol is version 4 and every write is a batch, several on-disk formats changed, and several config keys are now refused at startup. A data directory from an earlier build is refused at boot with the file, the version found and the remedy named; re-create the store or re-seed the node from a peer, and use SDKs built for this release.

From 0.0.1-preview to the next release: in place, node by node, under load. The procedure is built around checking rather than hoping:

1. See where every node stands. tulactl upgrade-status --nodes … reports each node’s build, its protocol windows and the cluster features it supports and has active, and names any node still on the previous release.
2. Upgrade followers one at a time, then the leader. Stop gracefully, install the new binary, start it on the same data directory, wait for it to be caught up and ready. tuladb_upgrade --data-dir <dir> run on a stopped node first gives a verdict: IN-PLACE UPGRADE SAFE or MIGRATION REQUIRED. The new release speaks its predecessor’s protocol and writes only files its predecessor can read until you finalise, so clients keep their SDKs throughout.
3. Roll back a node, any time before finalising. tuladb_upgrade --compat-with <previous release's format table> reads every file’s format version and answers ROLLBACK SAFE (start the previous binary on the same directory) or ROLLBACK NOT SAFE with the files it can’t open.
4. Finalise — the point of no return. tulactl upgrade-finalize activates the release’s upgrade-gated features, and refuses while any node is unreachable or not yet upgraded. A cluster formed on a release starts with that release’s gates already active.

Two rules that hold either way. There is no in-place downgrade past finalisation or a format change: to return to an older binary, restore a backup taken on it. And change timing after the binary, not with it: do the binary upgrade first and a Raft timing change in a later rolling restart, so the persisted vote fence keeps leases safe.

The wire protocol and SDK contract are versioned and contract-tested, which is what keeps the client side of upgrades boring.

Compliance posture

Stated plainly, because vague compliance language is worse than none:

• Certifications: none yet. No SOC 2, no PCI DSS attestation, no ISO 27001. TulaDB is preview-stage software from an early-stage company; certification work belongs to the road past preview. If your procurement requires a certified vendor today, we are not that vendor yet — we’d rather tell you here than in month three of an evaluation.
• Data residency: inherently yours. TulaDB is self-hosted — it runs in your cloud account or datacenter, in the region you choose. No TulaDB-operated service ever holds your data.
• Personal data and the immutable ledger. The ledger has no delete API by design — which is only compatible with erasure obligations if you keep personal data out of the ledger. The fields TulaDB stores are built for this: account ids are opaque 128-bit numbers, txn_id is a reference you derive, participant_id is numeric. The supported pattern is pseudonymization — identity, names, and contact data live in your systems of record where erasure applies; the ledger holds only opaque references to them. Treat this as an architectural requirement, not a suggestion, and validate it with your privacy counsel.
• Vulnerability handling. A published disclosure policy and /.well-known/security.txt, with fixes credited in release notes.
• Auditability. The strongest compliance story is the ledger itself: append-only history, durable rejected outcomes, an opt-in tamper-evident audit trail, and a hash-chained WAL verifiable offline (the chain verifier is a source-build tool in this release; tuladb_verify_store ships).

Multi-tenancy

The engine’s roles gate operation classes, not data slices — any authorized writer can address any ledger in a deployment. Ledgers give you namespacing, not authorization isolation. The supported patterns today:

• Deployment per tenant for hard isolation — a one-line install makes this more practical than it sounds.
• Isolation in your service tier — your API layer scopes tenants to ledgers and accounts before requests reach the engine, which is where per-tenant business authorization usually lives anyway.

If neither fits your platform’s model, that’s design-partner input we explicitly want.

Support

During the preview there is no paid support product or SLA to buy — support is the design-partner engagement: a direct line to the engineering team, structured evaluation, and jointly-run drills. Commercial support terms are part of the commercial licensing conversation (see licensing) as deployments move toward production.

The short version for your review board

Question	Today’s answer
Overload behaviour	Sheds with retryable statuses before the WAL; fail-stop where continuing would be unsafe — see Self-protection
Clouds	AWS: EKS installer; Google Cloud: no installer yet. Iceberg export tested on S3 Tables and BigLake/GCS — see Deployment
Release status	0.0.1-preview: first release, developer preview, not certified for production financial workloads; release chaos gate passed on this build (3 November 2026); six-hour multi-region soak not yet run; no multi-day soak
Acknowledged-write loss	Zero by design in a quorum cluster; explicit opt-in loss window on async single-node
Recovery time	Bounded (snapshot + WAL tail); measure with drills on your topology — no vendor RTO number published
Region loss	Backup + WAL-archive restore to an exact position; multi-AZ is the reference topology
Rolling upgrades	From 0.0.1-preview to the next release: in place, node by node, rollback until finalisation; no upgrade path from pre-release development builds
Certifications	None yet — preview-stage; self-hosted, so residency and infrastructure controls are yours
Erasure / GDPR	Keep PII out of the ledger (pseudonymous references); ledger immutability then works for audit, not against erasure
Multi-tenancy	Deployment-per-tenant or service-tier scoping; no in-engine data-slice authorization
Support / SLA	Design-partner engagement now; commercial terms with commercial licensing