Most of what teams spend on Databricks SQL Warehouses in non-production is spent while nobody is watching. In a development, staging, or QA account these resources are billed for every hour they exist, but the people who use them work a fraction of those hours. Nights, weekends, holidays, and the long tail of “we’ll get back to that environment next sprint” all meter at full price.
ZopNight closes that gap by scheduling your Databricks SQL Warehouses to run on your team’s hours and stop the rest of the time, without touching your data and without a migration. It is the most direct lever in FinOps, and for teams comparing tools it is where ZopNight pulls ahead of dashboard-first platforms like CloudHealth.
Why Databricks SQL Warehouses cost more than they should
Cloud providers bill Databricks SQL Warehouses by the hour whether or not anyone is using them, and most non-production fleets default to running 24/7 out of habit rather than need. At typical on-demand rates ($0.70 to $8.00/hr by warehouse size) an always-on instance quietly bills the same on a Tuesday afternoon as it does at 3 AM on a Sunday.
Here is the shape of it. Say a box runs at a typical on-demand rate of $0.17 an hour. Left on around the clock that is about $124 a month, because a month is roughly 730 hours. Confine it to a single-shift work week, about 50 hours, and you pay for 50 hours instead of 730. Your own rate and hours will differ, but the ratio is the point: in non-production, most of the meter runs while nobody is working.
The instinct is usually to reach for a smaller instance type. But rightsizing only helps a resource that is genuinely too big; it does nothing for a correctly-sized resource that simply runs when no one is around. The larger, easier win is refusing to pay for the hours nobody is working, and it carries none of the performance risk of down-sizing a box that might spike tomorrow.
Stopping and starting Databricks SQL Warehouses safely
ZopNight handles the stop and start via the Databricks SQL Warehouses API on every Databricks SQL Warehouses in scope, in dependency order so nothing comes up before what it depends on. A scheduled stop preserves your data exactly as a normal power-off would; ZopNight never terminates or deletes the resource, and idle detection watches CPU, network, and disk signals to surface the Databricks SQL Warehouses that are running but doing nothing.
In practice the setup is: Connect Databricks on GCP as a standalone account with an OAuth M2M service principal; ZopNight discovers SQL warehouses and their auto-stop settings; Schedule a warehouse to stop outside working hours and start before analysts need it; Combine with auto-stop recommendations so no warehouse is left running idle.
If you run Databricks SQL Warehouses you probably also run Databricks Clusters, Databricks Pools, and scheduling them together is where the dependency ordering earns its keep. Related reading: scheduling and cost optimization.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Does stopping a SQL warehouse lose anything?
No. Stopping a warehouse halts its compute only. Tables and query history are preserved, and the warehouse resumes serving queries when it starts.
How is this different from auto-stop?
Auto-stop reacts after a warehouse has been idle for a timeout. A schedule stops it proactively for the whole off-hours window, so you do not pay for the idle timeout every evening.
Which clouds support this?
AWS, Azure, and GCP. On AWS and GCP Databricks is a standalone connection; on Azure it rides the existing Azure subscription.