Clusters, wake and sleep

When you run a SQL query against Trino, Spark, or Doris, it needs a cluster. Clusters cost credits while they run, so Databasin keeps them asleep unless you're actively using them. This article explains how that works and the knobs you have.

The lifecycle

Sleeping → Waking → Running → Idle → Sleeping

• Sleeping: scaled to zero, no cost. A query wakes it on first contact.
• Waking: roughly half a minute. Queries queue until it's ready.
• Running: serving queries. Cost accrues.
• Idle: after a stretch of no activity, the cluster scales back down and sleeps.

The exact state names and timings vary by engine, but the shape is always the same: scale to zero when idle, wake on demand.

Waking from the UI

The first query after a nap takes longer than usual — you'll see a small "Waking cluster…" indicator while the cluster boots. Once warm, queries are fast again.

Wake can be triggered from a lot of places, and they all share one wake/status mechanism so they stay consistent:

• SQL Editor — hitting Run on a cold cluster.
• Notebooks — waking is implicit on the first cell run.
• Databasin One — the first question against a sleeping cluster wakes it.
• Semantic Model Builder — when the cluster backs the model.
• Gallery & Metrics — when a dashboard tile or metric re-runs.
• Data Exchange, Add Data, and even mobile — each can wake compute when it needs to read.

You don't have to think about which surface you're on — they're all driving the same underlying poll.

Two ways to size a cluster

Databasin has two separate sizing systems, and they don't use the same numbers. Knowing which one you're looking at saves a lot of confusion.

Pipeline and automation runs

When you configure a pipeline or automation run, you pick a size for that workload:

Note that an automation's Small is a lighter "consumption" profile (4 vCPU / 8 GB) tuned for lightweight jobs — the one place the two columns diverge.

Lakehouse SQL clusters

When you create a Lakehouse cluster for the SQL editor, the model is different: a coordinator plus a set of workers, sized together.

A couple of things worth calling out: there's a new X-Small tier for the lightest workloads, and a Lakehouse Small is a 4 vCPU / 16 GB coordinator with two matching workers — not the 8 vCPU / 32 GB you'd see on a pipeline run.

Credit mode

If your org is in credit mode (the default for new accounts), cluster creation is capped at the Small size. Moving to metered billing unlocks the larger tiers. See Credits and billing.

Admins vs. project users

There's a deliberate split in who sees what:

• Org admins and superadmins manage clusters through per-engine admin APIs — /trino/clusters, /spark/clusters, and /doris/clusters/* — and see the full status panel and lifecycle controls.
• Project-only users see cluster state through their connector's status feed. They get the bits that matter (waking / running / idle) without the admin tooling.

Most users don't need cluster-level visibility — they just need to know "is my query running?"

Manage clusters→

When a cluster won't wake

Rare, but it happens. If the wake indicator hangs well past the usual half-minute:

1. Check Credits — an exhausted-credit org can't wake new compute.
2. Confirm the cluster's status isn't stuck in a failed state.
3. Try another cluster if you have one available.

If none of that helps, open a support ticket and include the cluster ID and the time of the wake attempt. See Getting support.

Where to go next