> ## Documentation Index > Fetch the complete documentation index at: https://docs.e6data.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](/platform/reference/resource-naming-conventions) for the full rules. Running e6data in your own VPC? This page covers the Console UI. For the kubectl/CRD/GitOps workflow, see [CloudPrem cluster operations](/query/clusters/cloudprem-operations). ## Create a cluster 1. Open the Console and go to **Clusters**. 2. Click **Create Cluster**. 3. Fill in the fields: | Field | Required | Default | Description | | - | - | - | - | | 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](/query/clusters/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-suspend | No | On, 30 min | Suspend after this many idle minutes. See [Suspend and resume](/query/clusters/suspend-and-resume). | | Auto-resume | No | On | Resume automatically when a query arrives. | 4. 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**: | Setting | Range | Default | Description | | - | - | - | - | | 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](/query/clusters/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: | Protocol | Use for | | - | - | | 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](/platform/tokens/pat-and-service-account-keys), 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](/query/connect) for tool-specific guides and [Endpoints and cluster ingress](/query/clusters/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](/query/clusters/zero-downtime-upgrades). ### Cluster states | State | Meaning | | - | - | | 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](/query/clusters/lifecycle-states). ## See also * [Cluster sizing and scaling](/query/clusters/sizing-and-scaling) * [Suspend and resume](/query/clusters/suspend-and-resume) * [Lifecycle states and error codes](/query/clusters/lifecycle-states) * [Troubleshooting clusters](/query/clusters/troubleshooting) * [CloudPrem cluster operations](/query/clusters/cloudprem-operations) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.