Demand Shaping
Demand shaping is the practice of actively influencing how workloads consume compute, rather than reacting to whatever workloads arrive. Hyperscalers (AWS, GCP, Azure) and serverless data services (BigQuery, Athena, Snowflake) use demand shaping internally to keep their multi-tenant fleets profitable. Icebreaker brings the same techniques to your own data plane.
For the business framing, see Demand Shaping on the Icebreaker site. This page describes the mechanics — what Icebreaker actually does to each query, and which controls you have.
What Icebreaker shapes
Section titled “What Icebreaker shapes”Every SQL query that arrives at a Data Server is evaluated against four levers before it executes.
1. Right-sizing
Section titled “1. Right-sizing”The Logical Planner inspects each query and estimates its CPU and memory requirements. The query executor pod is created with resource requests and limits that fit the specific query — not a one-size-fits-all cluster default.
Small queries run on small pods, often packed onto idle capacity. Large queries get the resources they need without forcing the rest of the fleet to be over-provisioned.
2. Bin packing
Section titled “2. Bin packing”When a query’s pod fits on a node that already has spare capacity, Icebreaker places it there rather than provisioning new compute. This packs your fleet densely, especially when paired with Reserved Instances you have already paid for.
3. Smart queueing and traffic smoothing
Section titled “3. Smart queueing and traffic smoothing”When concurrent queries exceed available capacity, Icebreaker queues them rather than failing. The Job Manager applies backpressure so that bursts — 9 a.m. dashboard refreshes, agentic AI exploration spikes — do not trigger a cluster-wide scale event that you pay for and that then sits idle.
You configure how aggressive the queue is per Capacity Policy.
4. Capacity routing
Section titled “4. Capacity routing”Icebreaker can route queries to the most cost-effective capacity type your Capacity Policies allow:
- Spot Instances for cost-tolerant, restart-safe workloads.
- Reserved Instances and Savings Plans to make sure your negotiated capacity is actually used.
- On-demand as a fallback for time-sensitive, mission-critical jobs.
You declare these preferences on the Capacity Policy; Icebreaker picks per-query.
Controls you have
Section titled “Controls you have”Demand shaping is not automatic magic — it is policy you configure. The main controls live on the Capacity Policy:
| Control | What it does |
|---|---|
| Instance families | Limits which EC2 families Karpenter can provision |
| Capacity types | Enables / disables on-demand, RI, Spot |
| Quotas and limits | Caps total CPU / memory available to the Capacity Policy |
| Priority | Influences queue order across competing Capacity Policies |
See Manage Capacity Policies for the operational walkthrough.
What it looks like in practice
Section titled “What it looks like in practice”Think of Capacity Policies the way you think of a serverless data service like Athena or BigQuery: you do not define a warehouse per workload — the service picks the right compute per query, within the limits you have set. Icebreaker applies that model inside your data plane.
Most customers start with one broad Capacity Policy that reflects what their FinOps team has negotiated: the instance families they have Reserved Instances or Savings Plans on, the Spot tolerance their workloads can absorb, and a quota that caps total spend. Icebreaker routes every query — interactive dashboards, batch ELT, agentic AI exploration — into that spec and picks the right instance type and capacity for each query.
Additional Capacity Policies come in for exceptions — workloads that need different capacity than your default. Common reasons:
- A data science team needs access to specialized, expensive instance types (e.g., GPU or high-memory) that you do not want available to general workloads.
- Quota variability — different tenants, teams, or workload tiers need different capacity envelopes. A premium SaaS customer gets a higher quota than a free-tier customer; a production team gets more headroom than an exploration team.
- Availability zone constraints — a workload that must run in specific AZs (data residency, regulatory compliance, or latency to a specific data source) gets a Capacity Policy pinned to those AZs.
When you add a second Capacity Policy, you are not duplicating policy across workloads — you are carving out a slice of capacity that has different rules from your default.