Documentation Under Development

We're busy documenting the
Icebreaker Technical Reference.


Contact us for early access!

Tell us how to reach you.

Query Isolation

Guarantee the secure and successful execution of every query.

What's Wrong with Right-Sizing

  • Warehouses and clusters are sized for aggregate workloads, using one type of compute instance.
  • Individual queries have wildly different memory and compute requirements.
  • Auto-scaling forces overpaying for compute that isn't optimal for individual queries.

It is impossible to match a conventional cluster or warehouse to actual demand. You over-pay for idle compute that may not meet your performance goals.


With Icebreaker, every query runs in its own pod. You pay only for what you need. Plus: no shared memory, and no noisy neighbors. That's how our serverless data platform eliminates the expense and risks that clusters can't.

Key Concept • 3 Min Read

What is Query Isolation

Conventional data warehouses and clusters are built on a shared process model. Whether you call it a Warehouse or a Spark Executor, multiple queries from different users co-exist within the same memory heap and CPU thread pool. This architecture creates two systemic failures that attempts to "right-size" cannot fix.



1. The Logical Boundary Failure. In a shared cluster, isolation is a "polite request" made by software. When a chatty AI agent submits thousands of rapid-fire queries, or somebody runs a massive, unoptimized join, those queries don't just run slowly—they consume the shared resources of every other query in that cluster. Because they share a JVM, a single bad query can consume the entire environment's resources, crashing your production dashboards.


2. The Multi-Tenant Security Gap. Comprehensive security requires physical separation. In a shared-process environment, sensitive data queries (like HR or Finance) share a memory space with general-purpose analytics. If the engine's software-level access controls are bypassed, there is no physical "membrane" to prevent cross-query data leakage. (If you're curious to learn more, read this research paper Opens in a new tab ).



Icebreaker replaces shared processes with atomic-level, native Query Isolation. We move the isolation boundary from the warehouse or cluster to an ephemeral pod that executes exactly one individual query.


  • Ephemeral Sandboxing: Every incoming query is assigned to its own dedicated, single-use K8S pod. There is zero shared memory and zero shared state.
  • The Lightweight Engine: We use a Rust-based DataFusion engine inside each pod. This allows us to spin up a private, query execution environment in sub-seconds—avoiding the massive cold start performance penalty of traditional JVM-based containers.
  • Physical Resource Limits: Because each query is in its own pod, we enforce hard kernel-level limits on CPU and memory. Always-on AI agents can hit their own limits, but their jobs can never "leak" into the resources of another query.
  • Independent and Secure: With inherent query isolation, Icebreaker ensures that the success of a mission-critical query is never dependent on the behavior of its neighbors.

Icebreaker uses the same query isolation pattern that hyperscalers use to protect their own multi-tenant services. What was once their profit margin is now available for your private data cloud.

How Icebreaker Achieves Query Isolation

The architecture that brings hyperscaler-grade query isolation to the enterprise.

01

Diverse Compute Fleet

You specify the list of allowable compute instances.

  • Configure your fleet with the smallest and largest instance types you want to use.
  • Specify a few instance types for your day-to-day workloads.
  • Icebreaker will pick the best instance for the current workload at the best price.
02

Ephemeral Pod Execution

The "where" of Query Isolation.

  • Every query is right-sized to use an instance with appropriate memory and CPU. The instance may be running other jobs and have idle capacity, or a new instance may be spun up.
  • Every query is secure, as it runs in its own isolated, ephemeral pod.
03

Lightweight Query Engine

The "how" of Query Isolation.

  • Each Icebreaker pod runs its own lightweight query engine, built in Rust for the data lake.
  • No JVM overhead: no cold start, memory management penalties, or "leaky JVM" risks.

Comparing Isolation Models

Architectural Comparison: Icebreaker vs. Traditional Warehouses
Capability or CharacteristicTraditional WarehousesIcebreaker Data
Resource ContentionHigh: Multiple queries share a single JVM/process. One bad join can consume the entire cluster's memory and CPU.Minimal: Each query gets a dedicated K8S pod with specific resource requests and limits. It eliminates "Noisy Neighbor" effects from other queries.
Isolation ModelShared Cluster (logical)Per Query (physical)
Cost VisibilityDifficult: aggregate warehouse-levelEasy: pod-level
ScalingCoarse: cluster or warehouseGranular: elastic K8S pod per query