Which scaling mode?
- Predictable, steady load → Fixed size (a T-shirt size or a custom executor count).
- Variable or spiky load → Autoscaling (set min/max executors).
- A known target QPS → QPS-based scaling (planners auto-sized to your target).
- Long idle periods → Scale-to-zero (min = 0; auto-suspend handles the rest).
Fixed sizing
The cluster runs exactly the chosen number of executors at all times.
Best for steady, predictable workloads where you know the concurrency you need.
Autoscaling
Set a minimum and maximum executor count; e6data scales between them based on query load.
Enable window-based smoothing to use a sliding window that dampens aggressive scale up/down cycles - useful when query arrival is bursty but you don’t want the cluster thrashing.
QPS-based planner scaling
If you know your target queries-per-second, enable QPS-based scaling and e6data auto-calculates the planner replica count (planner replicas = ceil(target QPS / planner cores)). The system validates that you have enough executor capacity to sustain the target and warns if executors are under-provisioned.
Scale-to-zero
Set min executors = 0. When the cluster is idle and auto-suspend fires, all replicas drop to zero - no compute cost. The first incoming query triggers auto-resume (~30–90 s). Best for dev/staging, intermittent batch workloads, and cost-conscious teams. See Suspend and resume.Cost-control tips
- Start small at XS and scale up based on actual query patterns.
- Auto-suspend everything non-production, with a short idle timeout.
- Scale-to-zero for batch - if a cluster only runs scheduled jobs,
min = 0means you pay nothing between runs. - Autoscaling for production - a comfortable min for baseline latency, a max that covers peak.
Execution modes
A cluster runs in one of two execution modes, set under Advanced Settings:- Standard (default) - the full SQL surface area. Use for general-purpose and mixed workloads.
- Native - a vectorized path optimized for high-throughput, scan-heavy queries with simple filters, joins, and aggregations. Often 2–3× faster on matching workloads.