# HeliosDB Transaction Durability Commitment

| Item | Detail |
| --- | --- |
| Document | Transaction Durability Commitment |
| Version | 1.0 |
| Effective date | 2026-10-29 |
| Given by | Dimen Sigon OÜ, trading as HeliosDB, registry code 16757774, Ahtri 12, 10151 Tallinn, Estonia |
| Address of this document | https://partners.heliosdb.com/legal/transaction-durability |

## Change log

| Version | Date | Change |
| --- | --- | --- |
| 1.0 | 2026-10-29 | First published version. Replaces availability and uptime commitments for HeliosDB Cloud. |

## 1. The commitment in one sentence

**1.1** A transaction that HeliosDB has acknowledged as committed will not be lost because HeliosProxy is in the connection path, or because of the version of HeliosDB Full in use (in the Cloud Service, the version of the HeliosDB engine HeliosDB runs to provide it), including when that version is upgraded.

## 2. Where it applies

**2.1** This commitment forms part of, and applies under:

- (a) the HeliosDB Cloud Terms of Service, for the Cloud Service, including during its Experimental Period; and
- (b) the HeliosDB Customer Terms for Self-Hosted Commercial Licences, for HeliosDB Full under a Commercial Licence, and for HeliosProxy as supplied with HeliosDB Lite or HeliosDB Full under a Commercial Licence.

**2.2** It does not apply to software used only under an open-source or source-available licence without a Commercial Licence, or to any other service.

**2.3** It replaces any availability, uptime or service-credit commitment previously described for HeliosDB Cloud. HeliosDB gives no availability commitment.

## 3. Definitions

**3.1** In this commitment:

- **"Acknowledged Commit"** means a transaction, or a single write executed outside an explicit transaction, for which the HeliosDB service returned a successful completion to the client: for example, a successful completion of COMMIT over a database wire protocol, or a success response from the HeliosDB REST or MCP API for a write request. A transaction whose outcome the client did not receive (for example because the connection broke before the completion arrived) is not an Acknowledged Commit, but section 6.3 applies to it.
- **"Covered Cause"** means either of the following:
  - (a) **HeliosProxy in the path**: the presence or operation of HeliosProxy between the client and the database, including when HeliosDB places it in the path without the customer configuring it ("implicit use"), and its routing, connection pooling, read/write splitting, failover, retry, caching and transaction-replay functions; or
  - (b) **HeliosDB Full version**: a defect in a Generally Released version of HeliosDB Full, or in a documented upgrade, downgrade or rollback path between Generally Released versions of HeliosDB Full, including a change of storage or log format during such an upgrade. For the Cloud Service it means instead a defect in the version of the HeliosDB engine that HeliosDB runs to provide the service (on the effective date of this version, HeliosDB Nano), or in a version change HeliosDB applies to that engine.
- **"Covered Loss"** means an Acknowledged Commit whose effects are not present, in whole or in part, in the database afterwards, or are present in a corrupted form, where a Covered Cause caused or contributed to that result.
- **"Generally Released"** means a version that HeliosDB designates as generally released in the Release and Capability Matrix. Preview, nightly, release-candidate and source-build-only versions are not Generally Released.

## 4. Conditions for self-hosted use

**4.1** For self-hosted HeliosDB Full and HeliosProxy, the commitment applies when:

- (a) the versions in use are Generally Released and are combined as the Release and Capability Matrix supports;
- (b) the deployment uses the durability settings that the Documentation states are required for durable commits, and these have not been disabled or weakened (for example by turning off synchronous log flushing, using asynchronous commit modes, or using unlogged, temporary or in-memory tables);
- (c) upgrades follow the documented upgrade path for those versions; and
- (d) the storage and operating system honour write-flush requests as the Documentation requires.

**4.2** In the Cloud Service, HeliosDB is responsible for the conditions in clause 4.1, and they do not limit the commitment. Clauses 5.1(c) and 5.1(d) apply to the Cloud Service only as stated there.

**4.3** Until HeliosDB designates a Generally Released version of HeliosDB Full (or of HeliosDB Lite, for the HeliosProxy supplied with it) in the Release and Capability Matrix, no self-hosted deployment meets clause 4.1(a), so the commitment does not yet apply to self-hosted use. On the effective date of this version no such version is designated.

## 5. What it does not cover

**5.1** A loss is not a Covered Loss to the extent it is caused by:

- (a) a delete, update, truncation, schema change or restore performed by the customer, its users or its applications, or under its credentials;
- (b) hardware, storage, network or data-centre failure, fire, flood or similar events that destroy or damage the stored data and all of its replicated copies, where no Covered Cause contributed. For the Cloud Service, recovery from such events is described in clause 8.2 of the Cloud Terms of Service: restoring from the daily platform backup may lose up to about 24 hours of changes;
- (c) self-hosted deployments that do not meet clause 4.1;
- (d) for self-hosted use, features, protocols, drivers or engines that the Release and Capability Matrix lists as preview, skeleton, stub, planned, absent, not tested or unsupported, or does not list at all; in the Cloud Service, features that the console or the Documentation labels as preview;
- (e) data that is by design not durable: caches, including HeliosProxy result caches; in-memory key-value stores; and data held only in a client or driver;
- (f) modified HeliosDB software not supplied by HeliosDB, or third-party software in the path other than HeliosProxy;
- (g) a person using the customer's credentials, or malicious software on the customer's systems;
- (h) a known limitation that clause 5.3 or the Release and Capability Matrix lists, on the date of the transaction, for the engine version in use, together with a workaround, where the workaround was not used.

**5.2** Reads that return stale data from a replica or cache are not losses under this commitment, although HeliosDB treats them as defects where the Documentation promises otherwise.

**5.3** Known limitations on the effective date of this version:

- (a) In the HeliosDB Nano engine that the Cloud Service runs, concurrent single statements outside an explicit transaction that read and change the same row (for example UPDATE ... SET n = n + 1 from several sessions at once) can lose updates. Workaround: run such statements inside an explicit transaction, which reports SQLSTATE 40001 on a conflict so that the application can retry, or avoid concurrent read-modify-write statements on the same row. HeliosDB tracks this defect for correction and will publish a version of this commitment without this limitation once a corrected engine runs in the Cloud Service.

## 6. What HeliosDB does if a Covered Loss occurs

**6.1** For a Covered Loss, HeliosDB shall:

- (a) **Treat it as P1.** Reports are received and triaged at any time; a person from the HeliosDB pool starts investigating without undue delay, as the highest-priority work in the support queue, whether or not the customer has a support plan.
- (b) **Recover what can be recovered.** Use every copy HeliosDB holds or can access with the customer's permission (logs, replicas, backups, HeliosProxy records) to restore the lost Acknowledged Commits. Where restoration is not possible, identify the affected tables, keys and time window as precisely as possible so that the customer can re-apply the transactions from its own records, and help the customer do so.
- (c) **Report.** Give the customer a written incident report within 10 business days after confirming the Covered Loss, stating the cause, the affected versions and configuration, the time window, the affected data where it can be determined, the recovery performed, the fix and the measures taken to prevent a repeat.
- (d) **Fix.** Correct the defect in a Generally Released version (in the Cloud Service, in the engine HeliosDB runs) or withdraw the affected version, and record the defect against the affected versions in the Release and Capability Matrix and in the release notes, without identifying the customer.
- (e) **Credit or refund.** For a paid Cloud plan, credit 100 per cent of the fees for the billing month in which the Covered Loss occurred for the affected organisation. For a Commercial Licence, credit or refund 100 per cent of the licence fees for that month for the affected PDUs. During the Cloud Experimental Period no fees are charged, so no credit arises; items (a) to (d) still apply.
- (f) **Termination right.** Let the customer terminate the affected Cloud plan or Order with immediate effect within 60 days after receiving the report under item (c), with a refund of prepaid fees for the period after termination.

**6.2** These remedies do not exclude the customer's other rights and remedies, including damages, subject to the limitation of liability in the applicable terms. That limitation never limits liability for intentional breach or gross negligence or liability that cannot be limited by law, and the exclusion of indirect loss in those terms does not reduce the remedies in clause 6.1.

**6.3** Where the client did not receive the outcome of a transaction because of a Covered Cause (for example HeliosProxy failing over while a commit was in flight), HeliosDB shall, on request, help the customer determine from its logs whether the transaction committed. If HeliosProxy's or the database's records show that success was returned to the client, the transaction is treated as an Acknowledged Commit, and its absence is a Covered Loss where clauses 3 and 5 so provide.

## 7. How to report

**7.1** Report a suspected Covered Loss to support@heliosdb.com, with "Durability" in the subject line, and, if it may involve a security incident, also to security@heliosdb.com. Reports are accepted at any time.

**7.2** Please report within 30 days after becoming aware of the loss, and include as much as you can of: the time of the transaction; the client and driver used; evidence of the acknowledgement (for example client or application logs); the transaction identifier or log position if known; the versions and configuration in use; and whether HeliosProxy was in the path. A late report does not lose the commitment, but recovery may be harder.

**7.3** HeliosDB tells the customer, within 10 business days after receiving a report under this clause, whether it confirms a Covered Loss, and gives its reasons if it does not.

**7.4** HeliosDB keeps the evidence it collects for the investigation for at least 12 months after the report under clause 6.1(c).

## 8. Changes

**8.1** HeliosDB may change this commitment only by publishing a new version with at least 90 days' notice. A change that reduces it does not apply to a paid period, or to an Order term, that started before the change, unless the customer accepts it. Every version is published at the address at the top with its version, effective date, change log and SHA-256 fingerprint.