- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-04-2026 11:49 PM
Hi all,
I’m using Databricks Free Edition with a serverless SQL warehouse. I’m the only user in this workspace.
Warehouse config:
- Type: Serverless SQL
- Size: Large
- Max clusters: 2
Query:
SELECT
w.workspace_name,
ROUND(SUM(u.usage_quantity * COALESCE(lp.pricing.effective_list.default, 0)), 2) AS total_cost_usd
FROM system.billing.usage u
JOIN system.billing.list_prices lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_start_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_start_time < lp.price_end_time)
JOIN system.access.workspaces_latest w
ON u.workspace_id = w.workspace_id
WHERE
u.usage_start_time >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY
w.workspace_name
ORDER BY
total_cost_usd DESC;
Two back‑to‑back runs on the same warehouse give me:
Run 1:
- Query wall‑clock duration: 2 min 16 s
- Aggregated task time: 1.02 s
- Rows read: 334, Bytes read: 55.45 KB
- Bytes read from cache: 23%
Run 2:
- Query wall‑clock duration: 4 min 38 s
- Aggregated task time: 92 ms
- Rows read: 1,095, Bytes read: 68.32 KB
- Bytes read from cache: 100%
So the second run is actually “lighter” work (shorter task time, all data from cache), but the wall‑clock is roughly double. I also see from the docs that wall‑clock duration includes queuing/scheduling and possibly serverless startup.
My questions:
1. How exactly does serverless SQL compute work in Databricks Free Edition?
- Is the serverless pool shared with other customers/accounts in the same region, even if I have only one user in my workspace?
- Are there any special quota or throttling rules for Free Edition that could explain longer waits or cold starts?
2. Why might the second run be slower in wall‑clock even though bytes are 100% from cache and aggregated task time is only 92 ms?
- Is this likely due to waiting for serverless capacity (internal queue) or warehouse startup/autoscaling?
- Which fields in system tables or the query profile should I look at (for example, waiting_at_capacity_duration_ms, scheduling/queued time, etc.) to confirm that the extra minutes are from waiting, not execution?