Create and manage clusters
Create a cluster, configure its settings, connect to it, and manage its version and lifecycle.
A cluster is the compute layer of e6data. It receives SQL queries, plans execution, and distributes work across executor nodes. You size it for your workload; e6data handles auto-scaling, suspend/resume, and zero-downtime upgrades.
A cluster connects to one or more catalogs, and every query is routed to the cluster named in your connection string. The cluster name is 3–30 characters - letters (upper or lower case), digits, and hyphens - and is the routing key in every connection. It must start with a letter and end with a letter or digit, is case-sensitive, and cannot be changed after creation. See resource naming conventions for the full rules.
Create a cluster
Open the Console and go to Clusters.
Click Create Cluster.
Fill in the fields:
Name
Yes
-
3–30 chars; letters (upper or lower case), digits, and hyphens; must start with a letter and end with a letter or digit. Case-sensitive. Cannot be changed later.
Size
Yes
XS
XS (1), S (2), M (4), L (8), XL (16), XXL (32), or Custom (1–100 executors). See Cluster sizing and scaling.
Version
Yes
Latest
An available e6data release (the Cluster Runtime).
Query timeout
No
900 s
Maximum query execution time, 1–3600 s.
Auto-resume
No
On
Resume automatically when a query arrives.
Click Create. The cluster moves through Creating → Running and is ready for queries.
You choose a release version when creating or updating a cluster; the e6data team manages the release lifecycle (publishing, testing, deprecation), so you always pick from a curated, validated set.
Configure a cluster
After creation, tune these from Cluster → Settings:
Query timeout
1–3600 s
900 s
Maximum query execution time.
Result cache
on / off
off
Cache query results to speed up repeated queries.
Cache TTL
60–86400 s
300 s
How long cached results stay valid.
SQL transpiler
on / off
off
Translate SQL from another dialect before execution.
Transpiler dialect
snowflake / trino / databricks
snowflake
Source SQL dialect when the transpiler is on.
Execution mode (standard vs. native) and result caching as performance levers are covered in Cluster sizing and scaling.
Connect to a cluster
Each cluster exposes connection details from Cluster → Connection. The same cluster supports several protocols simultaneously - pick whichever fits your client:
JDBC / ODBC (gRPC)
BI tools, Java applications, drivers
REST API (HTTP)
Programmatic access, integrations, lightweight clients
PostgreSQL wire protocol
BI tools that speak Postgres (DBeaver, psql, Looker)
Python connector
Python applications and notebooks
For any method you need the endpoint hostname, port (typically 443 for gRPC/HTTP, 5432 for PostgreSQL), authentication (a personal access token, recommended), the catalog name, and the cluster name. Endpoints are tied to the workspace, not the cluster, so suspending or recreating a cluster keeps the endpoint stable. See Connecting to the engine for tool-specific guides and Endpoints and cluster ingress for allowlisting.
Manage and upgrade
Edit a cluster's settings or version from Cluster → Settings. Changing the version triggers a zero-downtime upgrade: the new version is brought up alongside the current one, traffic switches over once it's healthy, and the old version drains in-flight queries before shutting down - queries are never interrupted. See Zero-downtime upgrades.
Cluster states
Creating
Initial provisioning
Running
Active and serving queries
Updating
Configuration or version change rolling out (queries continue)
Suspending / Suspended
Draining / zero replicas, no cost
Resuming
Coming back from suspension (~30–90 s)
Failed
Irrecoverable error - check the error and retry or contact support
Degraded
Partially functional; may self-heal
The full state machine and error codes are in Lifecycle states and error codes.
See also
Last updated
Was this helpful?