Glossary

See Icebreaker Agent.

A credential issued once when an Icebreaker Agent is created in the Admin console. The Agent uses this token to authenticate its WebSocket connection to the Icebreaker control plane. If the token is lost, delete the Agent and create a new one.

An open table format for large analytic datasets stored in object storage. Iceberg describes tables as a set of Parquet data files plus a metadata layer that tracks snapshots, partitions, and schema evolution. Icebreaker runs queries against Iceberg tables; the Iceberg catalog is the authoritative source of which data files belong to each table snapshot. See Catalog integration.

An open, gRPC-based protocol for high-performance SQL query execution developed by the Apache Arrow project. Icebreaker Data Servers expose an Arrow Flight SQL endpoint; SQL clients connect via a JDBC driver or directly over gRPC. Arrow Flight SQL avoids the serialization overhead of ODBC/JDBC wire protocols by streaming results as Arrow columnar record batches.

One of the four Demand Shaping levers. When a query executor pod fits on a node that already has spare capacity, Icebreaker schedules it there rather than provisioning new compute. Bin packing makes dense use of Reserved Instance or Savings Plan capacity you have already paid for.

One of the four Demand Shaping levers. Icebreaker routes each query to the most cost-effective EC2 capacity type permitted by the applicable Capacity Policy: Spot for cost-tolerant workloads, Reserved Instances or Savings Plans to consume negotiated capacity, on-demand as a fallback for time-sensitive jobs.

See Data Catalog.

Icebreaker’s mechanism for preserving intermediate result fragments across query execution — and across executor failures. Before dispatching any query executor pod, the Logical Planner walks the query’s operation tree and evaluates the cloud cost of each fragment (S3 scan bytes, network transfer, compute time). Fragments that are expensive to recompute relative to their storage cost are durably preserved before execution begins.

When an executor is interrupted — for example, by a Spot instance reclaim — the preserved fragments survive. Retried execution resumes from the last checkpoint rather than re-scanning source data from S3. This makes Spot instances viable for long-running queries where the risk of full restarts would otherwise make them impractical.

Checkpointing is automatic — there is nothing to configure. The planner selects checkpoint locations based on cost, not on developer-defined stage boundaries.

See Caching and checkpointing.

A set of rules that governs how Karpenter provisions EC2 capacity in your cluster. A Capacity Policy defines which EC2 instance families and capacity types (on-demand, Reserved Instances, Spot) are eligible, and optionally caps total CPU, memory, or concurrency. The Icebreaker Agent translates each Capacity Policy into a Karpenter NodePool and a Kubernetes namespace in your cluster.

Capacity Policies are the primary control surface for Demand Shaping. One Icebreaker Agent can have multiple Capacity Policies — for example, a broad default policy and a high-memory policy for analytics workloads. Each Data Server is associated with exactly one Capacity Policy.

Legacy UI label: Compute Spec — see UI term mapping.

The address a SQL client uses to reach a Data Server. The connection URL is shown in the Data Server info modal in the Admin console; most SQL clients take the gRPC form directly, while JDBC clients use the JDBC form.

The URL format — hostname, port, and protocol — is determined by your ingress mode. Ingress is the Kubernetes mechanism that routes traffic from outside the cluster to services running inside it.

The Icebreaker-hosted SaaS layer, and one of the two halves of the Icebreaker platform. The other half is the data plane, which runs in your EKS cluster.

The control plane stores the authoritative registry of your accounts, users, agents, Data Servers, Capacity Policies, and catalogs. It also aggregates job monitoring, execution metrics, and billing data. When you make a change in the Admin console — creating a Data Server, updating a Capacity Policy — the control plane records it and pushes the updated desired state to your Icebreaker Agent over WebSocket. The Icebreaker Agent reconciles that desired state into your cluster and pushes actual state and metrics back.

The control plane never has credentials in your AWS account. It never receives source data, query plans, or query results — only aggregated metadata and metrics from the Icebreaker Agent.

An Iceberg REST-compatible catalog that Icebreaker connects to at query-planning time. The Logical Planner reads table schemas, partition lists, and snapshot references from the Data Catalog to produce a query plan. The catalog is yours — Icebreaker reads from it but does not manage or write to it. See Catalog integration.

Everything that runs inside your EKS cluster: the Icebreaker Agent, Data Servers, query executor pods, and supporting infrastructure. The data plane is where queries actually execute — source data, query plans, and query results never leave it.

The data plane connects to the control plane through a single outbound WebSocket connection made by the Icebreaker Agent. The control plane pushes desired state in; the Icebreaker Agent pushes actual state and metrics out. No inbound connection from Icebreaker to your cluster is required.

An Arrow Flight SQL endpoint that runs as a Kubernetes Deployment in your cluster, deployed by the Icebreaker Agent. SQL clients connect to the Data Server over JDBC or gRPC. For each query, the Data Server’s Job Manager dispatches an ephemeral query executor pod to process it. The Data Server itself is long-running; query executor pods are ephemeral.

A Data Server is associated with exactly one Data Catalog and one Capacity Policy.

Legacy UI label: Virtual Data Warehouse — see UI term mapping.

See also: Data Server internals.

The open-source, Rust-native query engine that runs inside each query executor pod. DataFusion parses the physical query plan, reads Parquet files from S3, and computes results. It starts in under a second, making per-query pod startup practical.

Icebreaker’s approach to governing how queries consume compute, at the individual query level. Rather than provisioning a fixed cluster and accepting whatever workload arrives, Icebreaker shapes demand through four levers: right-sizing, bin packing, smart queueing, and capacity routing. Controls are configured on Capacity Policies.

See Demand Shaping.

A high-performance, open-source remote procedure call framework developed by Google. gRPC uses HTTP/2 as its transport and Protocol Buffers as its serialization format. Arrow Flight SQL is built on gRPC; SQL clients can connect to Icebreaker Data Servers either through the Arrow Flight SQL JDBC driver or directly over gRPC. See JDBC for the JDBC connection option.

See Apache Iceberg.

A Rust binary that runs as a pod in your EKS cluster, and the record you create for it in the Icebreaker Admin console. You create the Icebreaker Agent in the console to obtain its token, then install it into your cluster with the Helm chart icebreaker/eyrie-agent, passing the token so it can authenticate. You install one Icebreaker Agent per EKS cluster.

Once running, the Icebreaker Agent connects to the Icebreaker control plane over an outbound WebSocket connection, receives desired state, and reconciles it into your cluster: Data Servers, Capacity Policies (as Karpenter NodePools), and the supporting infrastructure both depend on. There is no fixed pool of EC2 instances — capacity is provisioned by Karpenter on demand, per the Capacity Policies you define, as queries arrive.

The Icebreaker Agent manages long-lived infrastructure. query executor pods are dispatched by the Data Server’s Job Manager, not by the Icebreaker Agent.

See Icebreaker Agent configuration.

In Kubernetes, an ingress is a rule that routes traffic from outside the cluster to a service running inside it — the Kubernetes equivalent of a load balancer or reverse proxy entry point.

For Icebreaker, ingress is how SQL clients reach Data Servers. The Icebreaker Agent creates an ingress for each Data Server using whichever ingress mode your Icebreaker Agent is configured with.

Icebreaker supports two ingress modes (nginx and AWS ALB); your choice of mode is what determines the hostname and port in the connection URL your SQL clients will use. See Networking and ingress for a comparison and the URL format for each mode.

Java Database Connectivity — the standard API that SQL clients use to connect to data sources. Icebreaker Data Servers are accessible via an Arrow Flight SQL JDBC driver. The JDBC URL is displayed in the Data Server’s info modal in the Admin console, embeds the bearer token for authentication, and reflects your configured ingress mode. See Connection URL and Arrow Flight SQL.

A component of the Data Server that dispatches a per-query query executor pod for each logical plan the Logical Planner produces. The Job Manager monitors execution and reports per-stage timing metrics to the Icebreaker control plane.

An open-source Kubernetes node autoscaler that Icebreaker uses to provision EC2 nodes on demand. The Icebreaker Agent translates each Capacity Policy into a Karpenter NodePool, which defines which EC2 instance families and capacity types Karpenter may provision. When a query executor pod is scheduled but no suitable node exists, Karpenter provisions one that matches the NodePool’s constraints. Karpenter is a prerequisite for Icebreaker installations that use Capacity Policies.

A component of the Data Server that parses incoming SQL, reads table schemas and snapshot metadata from the Data Catalog, and produces a logical query plan. Before dispatching any query executor pod, the Logical Planner walks the full operation tree and evaluates the cloud-specific cost of each fragment — S3 scan bytes, network transfer, compute time — to decide proactively where to place checkpoints. It then hands the execution plan, with checkpoint locations embedded, to the Job Manager. On subsequent queries, the Logical Planner identifies which sub-trees can be satisfied by existing checkpointed fragments and dispatches only the genuinely new portions to fresh query executor pods.

See Logical Planner.

See Capacity Policy.

An ephemeral Kubernetes pod dispatched by the Job Manager for a single query. Each query executor pod runs the DataFusion query engine, reads source Parquet files directly from S3, computes results, and publishes them to a result channel. The pod is destroyed when the query finishes. No state is shared between query executor pods; no state persists across queries.

Query executor pods are scheduled in the Kubernetes namespace that corresponds to the active Capacity Policy. Karpenter provisions EC2 nodes for them on demand, per the Policy’s rules.

Icebreaker’s execution model in which every query runs in its own query executor pod, with its own kernel-enforced CPU and memory limits, with no shared memory or state with other queries. Query isolation eliminates noisy-neighbor interference and enables cost attribution at the individual query level.

See Query Isolation.

The component responsible for scheduling query executor pods onto available nodes and triggering Karpenter to provision new EC2 nodes when existing capacity is insufficient. Built on Karpenter. Works within the constraints of the applicable Capacity Policy.

A component of the Data Server that streams Parquet results from the result channel — backed by a co-deployed Redis instance — back to the SQL client over Arrow Flight SQL once an query executor pod publishes them.

One of the four Demand Shaping levers. The Logical Planner estimates each query’s CPU and memory requirements and creates its query executor pod with resource requests sized to that specific query, rather than a cluster-wide default. Small queries run on small pods; large queries get the resources they need.

One of the four Demand Shaping levers. When concurrent query demand exceeds available capacity, Icebreaker queues queries rather than failing them. The Job Manager applies backpressure so that sudden concurrency bursts — dashboard refreshes, agentic AI exploration spikes — do not immediately trigger large-scale EC2 provisioning events. Queue aggressiveness is configurable per Capacity Policy.

The Icebreaker Admin console uses several terms that differ from this documentation. The UI will be updated to use the new terms in a future release.

These terms appear in conventional data warehousing products and literature. Definitions reflect how the industry uses them; each entry notes where Icebreaker differs.

Depending on context:

• Kubernetes / EKS cluster — the Kubernetes cluster in your AWS account where the Icebreaker data plane runs. You bring and manage this cluster; Icebreaker does not provision it.
• Compute cluster — in conventional data warehousing, a pre-provisioned pool of query compute. See compute cluster.

Icebreaker has no compute cluster. EC2 capacity is provisioned on demand by Karpenter per Capacity Policy constraints, and released when queries finish.

The latency incurred when a query must wait for a compute resource to be provisioned before execution can begin — for example, a serverless warehouse that hasn’t processed a query in several minutes, or a Kubernetes pod that takes time to schedule on a new node.

In Icebreaker: Cold start occurs when no suitable EC2 node exists in your cluster for an arriving query executor pod and Karpenter must provision one. Startup time depends on EC2 instance type and availability. You can reduce cold start by keeping warm capacity (pre-provisioned nodes) in a Capacity Policy, at the cost of running idle nodes between queries.

A pre-provisioned pool of compute resources — VMs or containers — held running so that queries can start immediately. Common in systems like Redshift, Databricks, and Hive. Sized ahead of time to handle expected peak workload.

In Icebreaker: There is no pre-provisioned compute cluster. EC2 capacity is provisioned on demand by Karpenter per Capacity Policy rules, and released when queries finish. This eliminates idle-cluster costs; the trade-off is cold start on first query if no warm capacity exists.

A feature in some data warehouses (notably Redshift) that automatically adds compute capacity when the number of concurrent queries exceeds what the primary cluster can handle. Usually billed per-second on the additional capacity.

In Icebreaker: Concurrency scaling is inherent to the model. Each query gets its own query executor pod and Karpenter provisions additional EC2 nodes as needed, within the constraints of the active Capacity Policy. Smart queueing shapes how aggressively Icebreaker scales out under a burst.

A storage repository that holds raw or minimally-processed data in its native format — typically Parquet, ORC, or JSON files in object storage (S3, GCS, Azure Blob). A data lake stores data cheaply and at scale but does not, by itself, define schemas or manage transactions.

In Icebreaker: Icebreaker queries data in a data lake organized as Apache Iceberg tables. The Iceberg catalog provides the schema and transactional snapshot layer on top of raw S3 files. Icebreaker does not move or copy data out of your lake.

An architecture that combines a data lake’s low-cost object storage with a structured table format (Iceberg, Delta Lake, Hudi) to enable reliable, schema-aware, transactional queries on top of S3-resident data. Eliminates the need for a separate data warehouse for structured analytics.

In Icebreaker: Icebreaker is designed for the data lakehouse pattern. It runs SQL queries directly against Iceberg tables in S3, with no ETL or data copy step into a proprietary storage layer.

A centralized repository of structured, integrated data optimized for analytical query workloads. Traditional data warehouses (Teradata, Redshift, Snowflake) bundle compute and storage into proprietary systems you pay per-hour or per-query, with data stored in their format on their infrastructure.

In Icebreaker: Icebreaker provides the compute and query layer without the proprietary storage. Data stays in your S3 buckets in open Iceberg/Parquet format. Icebreaker never acts as a data copy destination or storage layer. Compute runs on your own EC2 capacity.

An architecture in which a query is broken into fragments and each fragment is executed simultaneously across multiple nodes. Traditional MPP warehouses (Redshift, Teradata, Vertica) use a fixed set of nodes coordinated by a leader; adding parallelism means resizing the cluster.

In Icebreaker: Parallelism scales with the query, not with a pre-configured cluster. The Logical Planner can produce multi-pod plans where query executor pods run in parallel across multiple EC2 nodes, with the degree of parallelism set per-query rather than per-cluster.

A performance problem in shared-process query engines where one query’s CPU or memory consumption degrades performance for other concurrent queries, because they share a runtime, JVM heap, or thread pool.

In Icebreaker: Noisy neighbor is eliminated by query isolation. Each query runs in its own Kubernetes pod with kernel-enforced CPU and memory limits. A query that exceeds its limits is terminated without affecting other queries.

A unit of concurrency in some data warehouses (BigQuery, Redshift) that represents a share of the cluster’s compute capacity. The number of slots limits how many queries can execute simultaneously; additional slots cost money.

In Icebreaker: There is no fixed slot system. Concurrency is governed by Capacity Policy quotas and smart queueing. The effective concurrency limit is the total capacity available under the active Capacity Policy.

A cache of previously-computed query results. Some warehouses (Snowflake, BigQuery) serve repeated identical queries from a result cache without re-executing them, returning results in milliseconds at no compute cost.

In Icebreaker: The equivalent concept is checkpointing, but it operates at a finer grain and with a different cost model. Rather than caching only final query outputs, the Logical Planner preserves intermediate result fragments at cost-optimal points in the operation tree. Partial overlaps between queries are exploited — not just exact matches. Cache invalidation is driven by Iceberg snapshot changes rather than TTLs, giving precise, automatic staleness detection. See Caching and checkpointing.

A managed warehouse mode (Snowflake serverless, BigQuery, Athena) where the provider handles resource provisioning automatically and charges per query. The customer does not manage a cluster, but compute runs on the provider’s shared infrastructure at the provider’s rates.

In Icebreaker: Icebreaker is serverless in the operational sense — you do not manage a cluster, and compute scales to zero when idle. But compute runs on your own EC2 capacity (your Reserved Instances, Savings Plans, and Spot allocation), not on Icebreaker’s shared infrastructure. You keep your negotiated rates and FinOps levers; Icebreaker provides the orchestration.

Snowflake’s term for a named, independently-scalable compute cluster. Each virtual warehouse is a pool of servers that you start, stop, and resize; you are billed per credit while it is running. Multiple virtual warehouses can query the same data concurrently without contention.

In Icebreaker: An Icebreaker Agent and the cluster it manages are roughly analogous: an independently-scoped compute environment for your data. The key difference is that there are no pre-provisioned servers — capacity is provisioned by Karpenter per Capacity Policy as queries arrive and released when they finish. There is no “running” or “suspended” state to manage.

A general term for an environment that runs analytical queries. In Icebreaker, the closest equivalent is a Data Server. For conventional definitions see: data warehouse, serverless warehouse, virtual warehouse.

A subsystem in traditional data warehouses (Redshift WLM, Teradata TASM) that routes queries to queues, assigns resource shares, and enforces concurrency limits. WLM configuration is typically a cluster-wide concern managed by a DBA.

In Icebreaker: Workload management is handled by Capacity Policies and Demand Shaping. Each Capacity Policy is a self-contained workload management rule: which EC2 capacity to use, what quotas to enforce, and how to prioritize queries that compete for capacity. You define one Capacity Policy per workload type rather than configuring a global queue hierarchy.