Clusters, wake and sleep
Cost-aware compute in Databasin: wake a cluster when you need it, let it sleep when you do not, and see exactly what each running engine costs.
When you run a query on Databasin Sail or Trino, 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.
On Databasin Sail the two halves sleep separately. The coordinator stays on by default, so BI tools and metadata browsing (SHOW, DESCRIBE, information_schema) answer straight away; the workers sleep after about ten minutes without work and start again when a query needs them, which can take a couple of minutes. The editor, notebooks and Databasin One say so while they wait. Scheduled starts can keep workers warm for a window you choose, such as weekday mornings.
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:
| Size | Pipeline run | Automation run |
|---|---|---|
| Small (S) | 8 vCPU / 32 GB | 4 vCPU / 8 GB |
| Medium (M) | 8 vCPU / 64 GB | 8 vCPU / 64 GB |
| Large (L) | 16 vCPU / 128 GB | 16 vCPU / 128 GB |
| X-Large (XL) | 32 vCPU / 256 GB | 32 vCPU / 256 GB |
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.
Databasin Sail clusters
A Sail cluster is a coordinator plus a set of workers, picked as one size. Medium is the default.
| Size | Workers | Task slots | Coordinator |
|---|---|---|---|
| XSmall | 1 × 4 vCPU / 8 GB | 4 | 2 vCPU / 4 GB |
| Small | 2 × 4 vCPU / 16 GB | 6 | 2 vCPU / 4 GB |
| Medium | 3 × 8 vCPU / 64 GB | 18 | 3 vCPU / 6 GB |
| Large | 4 × 16 vCPU / 128 GB | 32 | 4 vCPU / 8 GB |
| XLarge | 5 × 32 vCPU / 256 GB | 80 | 4 vCPU / 8 GB |
When you create or edit the cluster you can also pick a bigger, dedicated coordinator (for many notebook users at once) and choose whether the coordinator sleeps too. See Databasin Sail.
Trino clusters
A Trino cluster is also a coordinator plus a set of workers, sized together.
| Size | Coordinator | Workers |
|---|---|---|
| X-Small | 4 vCPU / 8 GB | 1 × 4 vCPU / 8 GB |
| Small | 4 vCPU / 16 GB | 2 × 4 vCPU / 16 GB |
| Medium | 8 vCPU / 64 GB | 3 × 8 vCPU / 64 GB |
| Large | 16 vCPU / 128 GB | 4 × 16 vCPU / 128 GB |
| Extra Large | 32 vCPU / 256 GB | 5 × 32 vCPU / 256 GB |
Worth calling out: a Trino 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), the onboarding wizard caps your first cluster at Medium. 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:
- Project admins manage clusters on the project's Clusters page (Databasin Sail, Trino and DuckDB), 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?"
When a cluster won't wake
Rare, but it happens. If "Starting workspace…" hangs well past the usual minute:
- Check Credits: an exhausted-credit org can't wake new compute.
- Confirm the cluster's status isn't stuck in a failed state.
- 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.