Operations & Economics
Documentation for the operational and financial characteristics of the show.fm infrastructure. Every entry in this section is grounded in measured evidence — not estimates — with the methodology recorded so numbers can be reproduced and trusted.
Purpose
This section exists to answer questions the product and finance teams ask regularly:
- What does it cost us when a user imports a back catalogue?
- What's the marginal cost of an additional episode?
- Where are we spending compute, and where is it near-free?
- How do we project infrastructure cost against user growth?
Answers here are measured, not modelled. Every cost claim links to a run log, a database query, or a Cloudflare Worker tail capture.
Contents
| Study | What it measures | Status |
|---|---|---|
| RSS Import — Baseline | Cost per episode for RSS back-catalogue imports (streaming audio, R2 storage, Worker + queue ops) | 2026-04-22 |
How to add a study
- Run the workload you want to measure under realistic conditions (prod Workers, prod Hyperdrive, prod R2 — ideally against a throwaway test entity in prod DB).
- Capture evidence:
wrangler tail --format json > ...for each worker in the path, Supabase SQL snapshots for DB counters. - Aggregate the capture files (CPU/wall times, byte counts, retry counts).
- Apply Cloudflare published unit prices to the measured unit counts — do not guess.
- Add a new markdown file here following the structure of the RSS import baseline: Context → Test Setup → Evidence → Cost Table → Extrapolation → Anomalies → Reproduction.
Entries should age-stamp: Cloudflare pricing changes, so rerun the benchmark and add a new dated entry when unit prices or our workload shape materially shift.