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.
• Waking: about a minute. You can run queries as soon as 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, spin up when needed.

Starting from the UI

Where you write queries, waking is a deliberate click — a sleeping cluster never starts just because you hit Run:

• SQL Editor and Notebooks — the toolbar shows Start workspace when compute is asleep ("Your workspace is asleep. Start it to run queries — it takes about a minute."). While it boots you'll see "Starting workspace…", then Connected.
• Databasin One — same contract: the sidebar's warehouse section shows a Start button, and the agent won't fire SQL until the cluster is ready.

Surfaces that read data on your behalf still wake compute when they need it:

• 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.

Either way, every surface drives the same underlying wake/status mechanism, so the state you see is consistent everywhere.

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 "Starting workspace…" hangs well past the usual 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