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: workers scaled to zero. On Sail the coordinator stays on unless you let it sleep.
- Waking: on Sail, workers take about 2–3 minutes to start, and a dedicated coordinator that has scaled to zero about 2–5 minutes. 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 coordinator and the workers sleep separately: the coordinator stays on by default, and workers scale to zero about 30 minutes after the last request. See How Sail works for the details, including scheduled starts.
Starting from the UI
How compute starts depends on where you are:
- SQL Editor: waking is a deliberate click. When compute is asleep, Run doesn't start it: the toolbar shows Start workspace, and while it boots you'll see "Starting workspace…", then Connected.
- Notebooks: running a cell on sleeping compute starts it, and the cell waits until it's ready, then runs.
- 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 from XSmall to XLarge. Medium (4 workers) is the default. Sail clusters and sizes has the full table, the coordinator options and how to pick.
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.