How the composable CDP cost calculator works

Deterministic, audit-ready cost formulas for a composable customer data platform built on your own cloud data warehouse, accounting for execution floors, warm-compute reuse, streaming headroom, and enrichment throughput. Every formula below is read from this app's own source, not summarised from it.

Open the calculator

Deterministic foundations

Core infrastructure cost formulations

Model A · Compute

Warehouse compute & auto-suspend tax

coldBilled = max(minBillingSec, querySec) cost = coldRuns × coldBilled × (rate/3600) + warmRuns × querySec × (rate/3600)

Every sync run either lands cold (compute was asleep, so it pays the warehouse's minimum billing floor even if the query finishes sooner) or warm (compute was already awake from an overlapping sync, so it pays only for the seconds it actually used).

minBillingSecPer-warehouse floor: 60s for Snowflake, BigQuery Editions and Redshift Serverless; 0 for BigQuery on-demand, Databricks SQL Serverless and provisioned Redshift

warmRunPctShare of runs landing on already-awake compute, set in Step 1

rateWarehouse $/hour, from the selected compute size

minimumIncrementWaste isolates the cold-run floor cost as its own line, so it can be argued with directly

Model B · Streaming

Always-on ingestion & stream workers

instances = ceil(avgRpm × burstFactor / rpmPerInstance) cost = instances × secPerMonth × instanceRate + (requests/1e6) × costPerMillionReqs

The ingestion endpoint is sized to sustained load with a headroom multiplier, then billed for every second of the month. It never scales to zero. Stream workers are billed separately, per event processed and per event forwarded downstream.

svcBurstFactorHeadroom multiplier over average RPM, default 1.25×

svcRpmPerInstanceRequests/minute one instance sustains, default 3,000

workerCpuMsPerEventCPU-ms per event for parsing and identity resolution

This is the only line item active every second of every month, regardless of sync frequency

Model C · Activation

Enrichment store & forwarding egress

nodes = ceil(lookups / (targetSec × nodeRps)) kvCost = minNodes × hoursPerMonth × nodeRate + burstNodes × burstHours × nodeRate egress = forwardedEvents × kbPerEvent / 1024²

The key-value store is provisioned for lookup throughput during a run, not average load. Node count is driven by how many profiles a sync's audience touches, not by total data volume. Egress multiplies directly with fan-out: the same event sent to three destinations bills three times.

kvNodeRpsLookups/second one enrichment node sustains, default 10,000

fanoutAverage destinations each matched event is sent to

egressPerGbCloud egress rate, published list price

Enrichment cost is driven by sync frequency and audience size, not by profile count alone

Auditable parameter matrix

Baseline cloud rates & billing shapes

Warehouse	Billing model	Minimum floor	Representative rate	Published source
BigQuery (on-demand)	Per TiB scanned	None	$6.25 / TiB	BigQuery pricingIowa (us-central1)
BigQuery Editions (slots)	Per second awake	60s per resume	$4.00 / hour (Standard, 100 slots)	BigQuery pricingIowa (us-central1), pay as you go
Snowflake	Per second awake	60s per resume	$2.00 / hour (X-Small, Standard)	Snowflake pricing, credits per sizeAWS US East (N. Virginia), on demand
Databricks SQL (serverless)	Per second awake	None	$2.80 / hour (2X-Small (4 DBU/h))	Databricks SQL pricing, DBUs per sizeAWS, Premium plan
Redshift Serverless	Per second awake	60s per resume	$1.50 / hour (4 RPU (minimum))	Amazon Redshift pricingUS East (N. Virginia)
Redshift (provisioned RA3)	Per second awake	None	$2.17 / hour (2× ra3.xlplus)	Amazon Redshift pricingUS East (N. Virginia), on demand

Published list prices for the region shown, checked against each source on 26 October 2026. Every rate above is editable in the calculator's own "Rate assumptions" panel. See the warehouse comparison for these rates run against a shared workload.

The services around the warehouse

Cost line	Rate	Published source
Batch sync jobs	$0.000018 per vCPU-second, $0.000002 per GiB-second (Cloud Run jobs, instance-based rate)	Cloud Run pricingGoogle Cloud, Iowa (us-central1)
Stream workers	$0.000024 per vCPU-second, $0.0000025 per GiB-second (request-based rate)	Cloud Run pricingGoogle Cloud, Iowa (us-central1)
Always-on ingestion service	$0.000018 per vCPU-second, $0.000002 per GiB-second (instance-based rate), $0.40 per million requests	Cloud Run pricingGoogle Cloud, Iowa (us-central1)
Enrichment store	$0.65 per node-hour, $0.17 per GiB-month of storage	Bigtable pricingGoogle Cloud, Iowa (us-central1)
Network egress	$0.12 per GiB (Premium Tier, first TiB)	Network pricingGoogle Cloud, Iowa (us-central1)
Platform floor	$450 / month	An assumption, not a list price: the metadata database, cache, monitoring and load balancer any deployment runs before it processes a single event.

Checked against each source on 26 October 2026.

Frequently Asked Questions

Why does a 25-second query bill 60 seconds on Snowflake?

Snowflake (like Redshift Serverless and BigQuery Editions) suspends compute when idle and re-warms it on the next query, and every resume bills a minimum of 60 seconds regardless of how long the query actually runs. A schedule of frequent, short syncs pays this floor on almost every run. The calculator reports this explicitly as the warehouse's minimum-billing floor, separate from the query's real compute cost.

What does "runs landing on warm compute" change?

If a second sync fires while the warehouse is still awake from the first, it skips the resume entirely and bills only its real query time: no fresh 60-second floor. Batching syncs onto a shared, tighter schedule raises this percentage and is the single biggest lever against the floor tax on time-billed warehouses.

Why is BigQuery on-demand priced completely differently?

On-demand BigQuery bills bytes scanned, not seconds of compute. Unlike the time-billed warehouses in this model, sync frequency is nearly free and there is no minimum-billing floor at all. What matters instead is how much of the table each query reads, which is a partitioning and clustering problem, not a scheduling one.

Does the enrichment store cost scale with total profile count?

Only indirectly, through audience size. The key-value cluster is sized for the lookup throughput a single enriched sync needs to finish within a target window, driven by how many profiles are in that sync's audience and how often enriched syncs run, not by how many profiles exist in the platform overall.