Skip to content

Distributed & Cloud

DistributedCloud

AetheriusDB runs as a single database across a wide range — from a local replica on a device, out to a cluster spanning multiple cloud providers. This section covers the features that make that work: keeping edge replicas in sync, controlling cloud cost, treating object storage as a native tier, and backing up and restoring a whole cluster.

These are advanced and cloud-oriented capabilities. Each page carries an availability badge — most are Beta or Roadmap rather than on by default — so you can tell what you can rely on today versus what is still evolving.

Clustering, multi-tenancy and high availability are premium features. They exist only when the license key grants them (cluster, multi_tenancy, replication); no flag or environment variable turns them on. To license them, contact the AetheriusDB team at aetheriusdb.com or aetheriuslabs.com. See Licensing → Premium features.

The same database stretches from a phone-sized edge replica to a multi-cloud cluster, so you don’t re-platform as you scale out. Reads can be served locally for zero latency, cost can follow policy across providers, and a whole cluster can be snapshotted and rebuilt without a bespoke backup pipeline.

  • Local-first, offline-capable — an edge replica answers reads with no network hop and merges its writes back automatically when reconnected.
  • Object storage as a native tier — S3/GCS/Azure are storage the engine reads directly, not an import step.
  • Whole-cluster backup/restore — snapshot and clone the cluster from object storage instead of scripting per-table dumps.
  • 0 ms reads at the edge. A local replica serves queries without leaving the device — no round trip to the cluster.
  • Boot query-ready from a backup in seconds. A restored cluster comes up answering queries from object storage, rather than replaying a long restore.
  • Edge Sync — run a local AetheriusDB replica for zero-latency reads and offline writes that merge back to the cluster automatically.
  • Query Pushdown — send the question to the machine holding the data and get back just the answer, so a summary’s reply stays small however large the table grows.
  • Cloud Arbitrage — an autonomous cost layer that moves eligible workload to the cheapest viable cloud location within your policy.
  • Cloud Runtime — object storage, streaming sources, and cross-cloud failover as native storage tiers and SQL primitives.
  • Cluster Backup & Restore — fast snapshots, incremental uploads to object storage, and clusters that boot query-ready from a backup in seconds.
  • Cluster Execution Engine — an orchestrator compiles SQL to 64-bit bytecode; workers run it in a register VM over their own column stripes and return only answers. With reference pages for the Tiny VM ISA, the Bytecode Compiler, the Worker Node, Pushdown Joins & Aggregates and the Wire Protocol Versions.
  • Shadow HA Streamer — asynchronous replication of a primary’s containers to its standby, driven by heartbeats, never blocking ingest.
  • Multi-Tenancy (Fluid Clusters) — one cluster, many tenants: every connection executes for one tenant, each tenant’s data sits in its own directory, noisy neighbours are throttled before they reach a worker, and a tenant snapshots and restores in constant time.
  • Cluster TransactionsBEGIN and COMMIT across the cluster, readers that only see committed data, instant rollback, write conflicts that fail fast, and a watchdog for stalled transactions.
  • Deletes, Updates & the VacuumDELETE and UPDATE mark and append; a background vacuum compacts files without blocking a reader or a writer.
  • Secondary Indexes on Cluster Tables — point lookups, ranges and LIKE 'prefix%' without a scan, on BIGINT and VARCHAR columns, kept through the vacuum and every snapshot.
  • VARCHAR in Cluster Tables — text columns you can insert, select, compare, prefix-search and index.
  • Engine Hardening Log — the phase-by-phase record of how the engine landed, what it measured, and what broke on the way.