Cloud Runtime

DistributedCloudObject StorageStreaming

Roadmap Planned · not yet usable · cloud-native tiering and streams-as-tables; verify before relying on it — SQL below is illustrative

What it is

The Cloud Runtime absorbs the cloud into the engine’s own storage and compute hierarchy. To the rest of the database, a remote object store (S3, GCS, Azure Blob) is simply the deepest storage tier. Pub/Sub topics and streaming sources appear as virtual tables you can JOIN against. External services such as a vision API present themselves as plain functions you call in SQL. The engine is meant to handle authentication, retries, transport, and fetching data on demand.

A single cluster can span multiple cloud providers concurrently, and a data block can be placed redundantly across providers in the same replication group. If a provider has a regional outage, internal data requests reroute to a surviving replica without dropping the client connection.

Roadmap feature

The cloud-native tiering, streams-as-tables, and cross-cloud failover described here are planned capabilities and not yet usable in production. The SQL below describes the intended interface and is illustrative — confirm the exact syntax and behavior in the release notes before depending on it.

Why it matters

Treating the cloud as an external system you connect to means adapters, glue code, polling, and bespoke failover scripts. Treating the cloud as a native tier means you write SELECT and the engine decides whether the bytes come from RAM, local disk, or an object store on the other side of the planet.

• Zero-code tiering — a declarative policy moves cold data to object storage; no migration scripts.
• Transparent rehydration — a query that touches an archived block pulls it back automatically.
• Streams as tables — join a live topic against a static table in one SQL statement.
• Multi-cloud failover — provider outages reroute to a surviving cloud without restarting the query.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#e8eaf0

  Q[Query]:::a --> E[Engine]:::a
  E --> R[RAM]:::g
  E --> D[Local disk]:::g
  E --> O[Object storage<br/>S3 / GCS / Azure]:::b
  E --> ST[Streaming source<br/>Kafka / Redpanda]:::b
  ST -. virtual table .-> E

How you use it

Tiering and streams are declarative. The cluster handles the moves; you write SQL.

-- Illustrative — declare a tiering policy. Cold data drifts to object
-- storage; the engine pulls it back automatically when a query needs it.
ALTER TABLE sales SET (
  archive_threshold = '7 years',
  archive_target    = 's3://aetherius-archive/sales/'
);

-- Register a Kafka topic as a virtual table.
CREATE STREAM SOURCE live_clicks
  FROM    'kafka://broker:9092/clicks'
  SCHEMA  (user_id BIGINT, url TEXT, ts TIMESTAMP);

-- Join a live stream against a static table — one SQL statement.
SELECT u.name, c.url, c.ts
FROM   live_clicks c
JOIN   users        u ON u.id = c.user_id
WHERE  c.ts > now() - INTERVAL '5 minutes';

-- Call an external service as a function. Auth and retries are handled.
SELECT id, image_analyze(image_blob) AS labels
FROM   satellite_data
WHERE  captured_at > '2026-05-01';

No staging tables, no CDC connector, no polling daemon — the design treats object storage, the stream, and the external service as native primitives in the query plan.

Key concepts

Term	Meaning
Object-storage tier	A remote object store exposed as the deepest tier of the storage hierarchy.
Cold-data archiving	Background migration of cold data from local storage to the object-storage tier.
Transparent hydration	When a query touches an archived block, the engine pulls it back to fast tiers automatically.
Stream source	A registered topic or queue that behaves like a continuously-updated table.
Cross-cloud redundancy	Data placed across multiple providers in one replication group for outage survival.

Notes & caveats

Tip

Combine object-storage tiering with Cloud Arbitrage so the cluster can pick the cheapest storage class that satisfies your residency rules — without you writing migration scripts.

The first query against an archived block pays a round-trip

For predictable warm-up after a long idle period, pre-fetch hot tables explicitly before benchmark windows.

Cloud Arbitrage →

Combine native tiering with price-aware automatic migration.

Cluster Backup & Restore →

Object storage as a backup target and DR anchor.

Edge Sync →

The other end of the spectrum — the edge reaches inward.