Cockroach Labs Estate economics What idle nodes, provisioned bytes and peak-sized bills cost, worked out from your estate.
  1. Nodes 150 baseline
  2. Avg CPU utilization 15.0% idle hardware
  3. Storage provisioned 3.0 TB plus 500 GB in S3
  4. Est. monthly saving 11% $1,000/m becomes $890/m

Step 7 of 8 - Pricing

You pay for the area, not the rectangle

Provisioned capacity is a flat ceiling sized to the busiest fifteen minutes of the day, plus headroom for the peak you didn't forecast. The gap under that ceiling is hardware you rented and didn't use.

Run a day, 40% headroom Steady Business hours Batch spike

Provisioned capacity left unused

not started

Pick a day above. The ceiling is already drawn: it's sized to a peak of 401 vCPU plus 40%, and you pay for all of it whether the workload turns up or not. That's under the 1,200 vCPU the estate runs on today, which was bought a cluster at a time and works at 15.0%, not sized to this curve.

028156100:0006:0012:0018:0024:00vCPUProvisioned561 vCPUConsumed180 vCPU avgProvisioned capacity versus consumption over 24 hoursOver 24 hours, a ceiling of 561 vCPU, set above a peak of 401 vCPU, costs 13475 vCPU-hours, while the workload actually consumes 4320 vCPU-hours: 68% of the provisioned capacity goes unused.
Provisioned
0 vCPU-hours
Consumed
0 vCPU-hours
Paid for, not used
0 vCPU-hours
Read this chart as a table
Mean demand per hour against provisioned capacity, in vCPU
HourDemandProvisionedUnused
00:00 81 561 480
01:00 81 561 480
02:00 82 561 480
03:00 81 561 480
04:00 82 561 479
05:00 83 561 479
06:00 81 561 481
07:00 111 561 450
08:00 188 561 373
09:00 260 561 301
10:00 319 561 242
11:00 360 561 202
12:00 388 561 173
13:00 390 561 172
14:00 371 561 190
15:00 334 561 227
16:00 279 561 283
17:00 207 561 355
18:00 133 561 429
19:00 81 561 480
20:00 82 561 479
21:00 82 561 480
22:00 82 561 480
23:00 82 561 480
How this is worked out
  • Demand is this estate's 180 vCPU mean, shaped by the preset you picked, which also drives step 1.
  • Capacity is sized at the day's peak of 401 vCPU plus the 40% headroom you picked, giving a ceiling of 561 vCPU. The headroom is an assumption rather than a published figure, so it's yours to argue with.
  • That peak is the 50 clusters' own peaks added up, because a provisioned estate buys each of them separately. Step 1's aggregate peak of 211 vCPU is the later, smaller question: what one pool needs once the workloads share it.
  • A ceiling that high averages 32.1% CPU across the day, which is the whole day's 67.9% of unused capacity counted the other way round. The pooled cluster on step 1 runs at 36.3% against a 37.5% setpoint. Neither number sets the other: this one is how far above the peak you buy, that one is what a controller is told to hold.
Where the storage number comes from

3 shared copies at 50% utilization (3/0.5 = 6), plus 1 copy in S3. Consolidate to lift utilization to 75%. Billed as used: the 2.0 TB on disk, not the 3.5 TB of capacity holding them.

500 GB of logical data becomes 3.0 TB provisioned plus 500 GB in object storage, a factor of 7× before the cost model sees it.

The console quotes no storage estimate for Plenum - the bytes aren't known until they're held - so this is the demo's model of the meter, not a figure you can read back off a price page.