Idle instances that sleep, and the energy we measure

A database instance that runs all night for a team that works by day draws power for nothing. Every InventDB customer has their own instance on its own virtual machine, which makes that waste easy to see and easy to remove: when an instance has nothing to do, our control plane stops its machine, and the next request starts it again.

This article explains what counts as idle, the order in which an instance is put to sleep so that nothing is lost, what a caller sees when it sends the first request to a sleeping instance, how scheduled backups still run, and how we measure the energy and carbon involved, including what that measurement leaves out.

What counts as idle

Each instance keeps one timestamp: the time the last customer-facing request started. Every request from a person, an application or an agent moves it forward, whether it comes from the console, the REST API, SQL over HTTP or an MCP tool call. Requests that only watch the instance leave it alone. Health checks, version probes, metrics scrapes and our control plane's own calls do not count, because otherwise the monitoring would keep every instance awake forever.

Our control plane reads that timestamp from every running instance at a regular interval. When the last customer-facing request is older than the configured idle period, it puts the instance to sleep. Two situations count as activity without any request. A freshly started instance counts as active from the moment it boots, so a woken instance stays up for at least one idle period. An instance that is running a backup reports itself as busy for as long as the backup runs, so a long backup in the middle of the night is never cut off.

The timestamp is taken when a request starts rather than when it ends, so the idle period is set longer than the longest single request an instance serves, such as an AI agent working through a multi-step answer.

Going to sleep without losing anything

Stopping a database's machine is safe only if it happens in the right order. Our control plane does three things, in this sequence:

1. Take over the address. It points the instance's address at itself, so a request that comes in during or after the stop starts a wake instead of failing. If it cannot do this, it does not stop the instance. An idle instance left running costs a little money; an address that nothing can wake would cost the customer their service.
2. Shut the database down cleanly. It asks the server to stop. The server runs a final checkpoint, syncs everything to disk and records that it stopped cleanly, so the next start opens the database without a recovery pass. If a clean shutdown cannot be confirmed, the machine is stopped anyway and the next start runs the engine's crash recovery, which exists for exactly that case.
3. Stop the machine. The virtual machine stops and uses no compute. Its encrypted data volume stays attached and keeps every byte.

Waking on the first request

While an instance sleeps, our control plane answers its address. When a request comes in, the control plane starts the instance's machine and then handles the waiting request according to the kind of client that sent it:

• A browser gets a short waiting page, which checks the instance's status and moves on to the real page as soon as the instance answers.
• Any other client, such as a script, an integration or an AI agent, is held. The control plane keeps the request open, up to a time limit, until the instance is healthy, then forwards that exact request, with its method, path, headers and body, and streams the response back. The client sees a slower response than usual and nothing else, so it needs no special handling for sleep.

As the machine boots, a start-up step runs before the database does. It mounts the data volume, installs the platform version that is due if a new one was released while the instance slept, and refuses to start the database if the data on disk uses a storage format outside the range that version supports. The database process itself will not start unless its data volume is mounted, so an instance can never wake on an empty disk and begin a new, empty database. Once the instance passes its health check, our control plane points the address back at it, and later requests go straight to the instance.

Work that does not wait for a request

A stopped machine runs nothing, so timed work inside an instance needs something to wake it. Backups are the timed work our control plane handles. Each instance reports the time of its next scheduled backup, and our control plane wakes a sleeping instance shortly before that time. The instance's own scheduler sees that a backup is due and runs it, and the backup holds the instance awake until it finishes. If an instance slept through a backup time anyway, its scheduler runs the missed backup on the next start. Our article on hot backups describes the rest.

Apart from requests, backups are the only timed work our control plane wakes an instance for. Any other work an instance would start on a timer runs only while the instance is awake. In InventDB SOAR, a workflow that must run at an exact time can be started by a webhook call from an external scheduler instead: the call is a request, so it wakes the instance and triggers the workflow.

How we measure the energy

Because our control plane starts and stops every instance, it knows exactly when each one was running. It writes a row to a lifecycle ledger each time it starts or stops an instance's machine, recording the instance, its size tier, its processor architecture and its region. That ledger is the input to our energy and carbon figures. The method follows the Green Software Foundation's Software Carbon Intensity specification and uses the open Cloud Carbon Footprint coefficients. For each instance over a chosen window:

running_hours = sum of (stop - start) for each start/stop pair
                # a start with no stop yet counts as running until now
energy_kWh    = running_hours * watts(size, architecture) * PUE / 1000
carbon_kg     = energy_kWh * grid_intensity(region)

always_on_kWh = window_hours * watts(size, architecture) * PUE / 1000
saved_kWh     = max(always_on_kWh - energy_kWh, 0)
saved_kg      = saved_kWh * grid_intensity(region)

The coefficients are fixed and published. Watts are the average power at moderate utilisation for each instance size, from Cloud Carbon Footprint v0.43. The method also publishes a projected figure for ARM processors, about 40% below x86, and uses it for instances that run on ARM:

PUE, the data centre's overhead for cooling and power distribution, is 1.135, the published 2024 global average for the data centres our instances run in. Grid intensity is the carbon released per kilowatt-hour by the region's electricity grid, from Electricity Maps 2025 averages and, for India, the Central Electricity Authority baseline: 0.708 kg per kWh for India (Mumbai), 0.379 for US East (N. Virginia), 0.290 for US West (Oregon), 0.420 for the EU (Ireland), 0.040 for the EU (Stockholm), and 0.500 for any region the method does not list.

Here is the arithmetic for one hour, using only those coefficients. An hour of running on a size rated at 17 W uses 17 × 1.135 / 1000 = 0.0193 kWh. In India that is 0.0193 × 0.708 = 0.0137 kg, about 13.7 g of CO₂e; the same hour in Stockholm is about 0.8 g. Every hour an instance spends asleep is an hour of that figure that the comparison counts as avoided.

What the figure leaves out

• Storage. The data volume persists while the instance sleeps, and storage still draws power. The figures cover compute only, so the accurate claim is zero compute energy while asleep, which is different from zero energy.
• Everything outside the instance. Network traffic, the carbon embodied in the hardware, and the always-on control plane that wakes instances are not in the per-instance figure. AI calls made by InventDB SOAR are reported on its AI usage page and are not counted here.
• Actual utilisation. The watts are an average at moderate utilisation rather than a reading from the processor, so a busy hour and a quiet hour of running count the same.
• No projections. The saved figure compares against an always-on instance over the same measured window, never a forecast. If the ledger holds less history than the window asked for, the window shrinks to match: a 30-day request with 12 hours of data reports 12 hours.

For the same reasons, we present these as measured running time with estimated energy and carbon, and we do not describe instances as carbon-neutral.

What sleeping costs you

The cost is on the first request after a quiet period, which waits while the machine boots, the start-up checks run and the database opens. Requests after that run at normal speed. A woken instance stays up for at least one idle period, so a person who opens the console in the morning pays the wait once rather than on every click.

What you do

Nothing. Instances of InventDB Serverless and InventDB SOAR sleep when idle and wake on the first request, and their storage always persists. A client written for an always-on database works unchanged. After a quiet night, the first call below waits while the instance wakes and then returns its answer; the second returns at normal speed:

# first call after a quiet period: held while the instance wakes
curl -X POST https://<your instance>/sql \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"sql": "SELECT COUNT(*) AS leases FROM pms.leases"}'

# the same call again: answered by the running instance

If a job must run at a fixed hour, have it start with a request to the instance, and the instance will be awake to do it.