Workers

Altertable Workers are the data-plane runtime that executes queries, reads and writes Parquet files, connects to data sources, and streams results. Every Altertable environment uses Workers; the choice is where they run.

• Hosted Workers run on Altertable-managed infrastructure. This is the default; you create an environment and Workers are provisioned for you.
• Self-hosted Workers run inside your own cloud (Kubernetes or Docker). The hosted control plane remains the same; the Worker handles compute and source connectivity inside your network.

Both modes use the same runtime, same UI, and same control plane. Hybrid setups are natural: use Hosted Workers for shared exploration while a Self-hosted Worker handles production data that cannot leave your VPC.

Architecture

The control plane manages catalog metadata, authentication, connection configuration, orchestration, the UI, and billing. Workers handle everything on the data path: source connectivity, query execution, Parquet reads and writes, object storage access, local cache, and result streaming.

┌──────────────────── Hosted control plane ──────────────────────────────┐
│  Catalogs · Auth · UI · Orchestration · Billing · Audit · Metadata     │
└──────────────────────────┬─────────────────────────────────────────────┘
                           │ enrollment + config
              ┌────────────┴────────────┐
              │                         │
    ┌─────────▼──────────┐   ┌──────────▼──────────┐
    │   Hosted workers   │   │ Self-hosted workers │
    │  (Altertable cloud)│   │   (your cloud/VPC)  │
    │                    │   │                     │
    │  Query execution   │   │  Query execution    │
    │  Source access     │   │  Source access      │
    │  Parquet I/O       │   │  Parquet I/O        │
    │  Local SSD cache   │   │  Local cache        │
    └────────────────────┘   └─────────────────────┘
Copy

Under the hood, each Worker is a Rust binary built around DuckDB. It speaks to the control plane over a secure tunnel, executes analytical work locally, and operates on data in object storage.

Self-hosted Workers

Self-hosted Workers are available in early access. They are designed for environments where:

• Production data sits behind private networks and cannot be exposed to a public endpoint.
• Credentials and raw data must not leave your infrastructure.
• Compute scaling is an infrastructure decision you want to own.

How enrollment works

1. Generate an enrollment token in the Altertable UI or API.
2. Install the Worker with Helm (Kubernetes) or as a Docker container, passing the token at startup.
3. The Worker connects to the control plane over TLS, registers itself, and appears online in the UI.
4. Pin connections to the Self-hosted Worker so queries against those sources run inside your network.

After enrollment the Worker fetches its configuration from the control plane, opens tunnels to configured data sources over your private network, and executes work locally. Raw data never round-trips through the control plane.

Networking

The Worker initiates an outbound TLS connection to worker-registration.altertable.ai. No inbound ports need to be opened on your side. Your databases and object storage do not need public IPs, bastion hosts, or vendor-facing endpoints.

Learn more

• Architecture: Infrastructure details on Workers, cache layers, and distributed storage
• Encryption: How credentials and data are encrypted in transit and at rest
• Regions: Available deployment regions and data residency
• Performance: Cache behavior and benchmark methodology