Our first billing backend ran on two n1-standard-4 instances and a manually tuned Postgres cluster. It cost real money even when customers were asleep. Moving to UsageBox’s serverless stack cut the bill and the on-call rotation. Here’s how the numbers worked out.
Cost Profile Before the Switch
- Two always-on VM instances: ~$420/month
- Managed Postgres with replicas: ~$300/month
- Monitoring, backups, patch windows: a few engineer days every sprint
None of that spend moved with revenue. Idle weekends cost the same as peak launches.
Serverless Tradeoffs
- Cloud Run: scales to zero. We pay only for CPU seconds while handling ingestion bursts.
- Firestore: storage and read/write costs track directly with event volume.
- Pub/Sub + Cloud Tasks: cheap queueing with built-in retry logic so we stopped running our own workers.
The infrastructure bill now follows usage curves instead of staying flat.
Numbers After Migration
- 10k events/month ≈ $40 all-in
- 1M events/month ≈ $260 (mostly Firestore writes and reads)
- No VM patching, no database failover drills, no weekend pager duty
We still budget for spikes, but Cloud Run handled a 12x launch-day surge without intervention. The alternative would have been over-provisioning instances just in case.
How to Keep Costs Predictable
- Track ingestion volume and average event size weekly, Firestore billing is sensitive to payload size.
- Batch tiny events when possible. We aggregate noisy signals into five-second windows to avoid write amplification.
- Set alerts on Cloud Run concurrency so you know when to bump limits before throttling kicks in.
- Export usage metrics to BigQuery or your warehouse to compare infrastructure spend against billing revenue.
Serverless won’t always be the cheapest option, but for elastic workloads like metering it keeps costs and maintenance aligned with the value you deliver.