Persistence and concurrency

wabe Cloud uses buffered writes. A standalone server operator can choose a durability mode.

SQL transactions use buffered acknowledgements. A successful Hrana COMMIT confirms the transaction’s publication in the running disk; it does not wait for object-store persistence or initiate a flush. Finishing a cursor does not commit an open transaction.

Buffered writes

A successful buffered write confirms that the complete new file, KV change or SQL transaction was published in RAM and is readable. Pending writes can be lost if the process fails before persistence.

The server persists writes in the background. The configured interval defaults to 10 seconds. Size triggers can flush earlier; storage latency and failures can delay completion. The interval is not a guaranteed maximum data-loss window. Treat a successful explicit flush as the confirmation barrier for preceding writes.

Confirm a persistence barrier

Inside disk JavaScript, await fs.flush() confirms earlier file, KV and SQL writes on that disk. For direct HTTP flush on a standalone server, see self-hosted flush.

Self-hosted remote mode

Operation	Acknowledgement in remote mode
File mutation	Waits for a forced persistence flush.
KV put/delete/batch	Waits for its write to be persisted by the background policy or a separate flush. It does not initiate a flush.
SQL COMMIT	Confirms the buffered SQLite transaction. Use explicit disk flush for a persistence barrier.
Read	Returns data without requesting persistence.

A remote KV call can wait until the next background flush plus storage I/O. Set client and execution deadlines to cover that wait. Several sequential KV writes may wait across several intervals; use a batch for related mutations.

Concurrent requests

The HTTP server has no global request-count cap. Requests can run concurrently, subject to data locks, storage backpressure and runtime limits. Concurrent replacements of a file or KV key use the last published value. Individual files publish as complete versions.

SQL has a separate configurable execution limit, defaulting to 16 active requests per router. Requests sharing one Hrana session execute sequentially; SQLite controls locking between connections. Other sessions and databases can use available execution slots. Transactions can span HTTP requests and retain their disk lease until COMMIT, ROLLBACK or the absolute 60-second transaction TTL. Eviction waits for that lease.

KV batches provide atomic publication within one namespace. A JS invocation containing several file and KV calls does not wrap those calls in a transaction. A later script error does not undo prior writes.

Disconnects and retries

A timeout or disconnect after publication has an uncertain acknowledgement outcome. The write may already be visible or persisted. Inspect the resource before retrying a mutation whose repeated execution changes its meaning. The API has no idempotency-key facility.

Evict and reopen

Eviction drains requests for the disk, persists pending writes, closes the active disk and discards its local caches. Stored data remains. A later request reopens the disk. Long-lived or unconsumed response streams can delay eviction. Graceful server shutdown also drains and persists data.