Warehouses and scaling

A VegaDB warehouse is an independently managed compute pool with one SQL endpoint. It reads the catalogs authorized for its workspace and does not own the underlying data.

Choose a warehouse profile

Workload	Starting profile	Optimize for
Development and notebooks	X-Small or Small	Low idle cost and fast startup
Scheduled transformation	Medium, auto-suspend	Throughput during a bounded window
BI and dashboards	Medium or Large	Concurrency and predictable latency
Large joins or backfills	Memory-optimized	Working-set headroom and throughput
Customer-facing analytics	Dedicated, multi-cluster	Isolation, concurrency and availability

Profile names and quotas depend on the account plan. The warehouse detail shows vCPU, memory, minimum and maximum scale, queue policy and regional availability.

Lifecycle

Create

Choose a region, profile, minimum and maximum scale, auto-suspend period and network policy.

Start

VegaDB provisions the warehouse and makes its stable SQL endpoint ready. Connections can wait for resume or fail fast according to the client policy.

Scale

Automatic scaling responds to admitted concurrency and workload pressure within your configured limits. Manual resizing changes the profile for later work.

Suspend

Idle suspension stops compute billing while preserving catalogs, tables, permissions, query history and the endpoint configuration.

Workload isolation

Create separate warehouses when one workload must not consume another workload’s concurrency or memory budget. A common production layout is:

ingestion: VegaFlow loads and scheduled transformations;
bi-serving: dashboards and semantic tools;
data-science: notebooks and exploratory SQL;
app-serving: latency-sensitive product queries.

Isolation does not grant data access. Users and service principals still need permission on every referenced catalog and object.

Each warehouse admits work according to its concurrency policy. When capacity is full, queries queue until a slot becomes available or the queue timeout expires. Use a dedicated warehouse or multi-cluster profile for bursty dashboard traffic rather than letting it compete with long transformations.

Inspect query history for queue time, execution time, bytes scanned, spill, cache use and cancellation reason before resizing. More compute helps parallel work; it cannot fix unnecessary scans, severe data skew or an unbounded result.

Auto-suspend and resume

Set auto-suspend long enough to avoid cycling between closely spaced jobs. Scheduled VegaFlow work can resume its target warehouse before execution. Applications that require continuous low latency should keep a minimum running cluster or use a profile designed for automatic multi-cluster scaling.