Skip to main content
Suspension is the primary cost-control lever for clusters. A suspended cluster has zero replicas, consumes no compute, and costs nothing. The first query after suspension resumes it automatically.

​
Auto-suspend

When no queries have run for the configured idle period, the cluster suspends automatically. Keep auto-suspend on for all non-production clusters with a short idle timeout. For always-on clusters, increase the timeout or disable it.

​
Manual suspend

Suspend a cluster immediately from Cluster → Suspend. The operation is idempotent - suspending an already-suspended cluster succeeds silently.

​
Auto-resume

When a query arrives at a suspended cluster, e6data resumes it automatically:
  • HTTP / gRPC: the request is held until the cluster is ready (up to a 300 s timeout).
  • PostgreSQL wire: the client receives SQLSTATE 57P03 (“cluster is being resumed, please retry”). Standard drivers (libpq, psql, recent pgjdbc) retry automatically.
The first query after resume waits for the cluster to come back; larger clusters (XL+) may take longer. You can also resume manually from Cluster → Resume.

​
Resume failure

If a cluster fails to come back, e6data automatically re-suspends it and marks it “Suspended after failed resume.” Check the error in the Console, fix the underlying issue, and resume again.

​
What’s preserved across suspend/resume

  • Replica counts are stored before suspension and restored on resume.
  • If autoscaling is enabled, the cluster resumes at the min executor count (not the pre-suspension count), avoiding resuming an over-scaled cluster.
  • If no history is available, the cluster falls back to a safe default (1 executor).
For pausing all compute in a workspace at once (rather than per cluster), see Workspace settings.

​
See also

Last modified on September 29, 2026