Supabase cached egress is $0.03/GB: cost of serving a 20 MB AI clip

Supabase's changelog lists cached Storage egress at $0.03 per GB, which the entry describes as three times cheaper than origin egress. For a 20 MB clip that is $0.0006 per cached view, so egress is a small line next to the cost of generating the clip, but it scales with views rather than with renders.

The 20 MB size is an assumption chosen to make the arithmetic easy to check. Replace it with the size of your own exports before drawing a conclusion.

What the Supabase entry says

The figure comes from a Supabase changelog entry dated 2025-08-22, read on 2026-10-03. It is older than most of the items in a fall 2026 review, so confirm it against the live pricing page before you commit a budget to it.

Worked arithmetic for a 20 MB clip

Egress is size times views. Using 1 GB as 1,000 MB for round numbers, a 20 MB clip is 0.02 GB per full view. The table assumes every view downloads the whole file and every request is served from cache; a cache miss is billed at the origin rate, which is the implied $0.09 per GB above.

Copy the file, or link to the Sume URL

A completed Sume job returns artifacts whose url is a media.sume.com address, and the docs say to use those Sume media URLs from the result rather than raw provider URLs. If your page only needs to play the clip, you can link that URL and your Storage egress is zero. Copying into your own bucket makes sense when you need your own access rules, your own domain, or a retention policy you control yourself.

If you do copy, copy once, at the moment the job reaches completed, and store the Sume job id beside the stored path. The webhook page recommends using job_id as the idempotency key on your side, so a retried delivery should not trigger a second copy.

A cost estimator you can run

This script turns a file size and a view count into dollars at the cached rate and at the implied origin rate. It takes the rate as an argument so you can change it when Supabase changes the price.

def egress_cost(size_mb, views, usd_per_gb=0.03, cached_share=1.0, origin_multiplier=3.0):
    gb = size_mb / 1000 * views
    cached = gb * cached_share * usd_per_gb
    origin = gb * (1 - cached_share) * usd_per_gb * origin_multiplier
    return round(cached + origin, 4)


if __name__ == "__main__":
    for views in (100, 1000, 10000):
        best = egress_cost(20, views)
        mixed = egress_cost(20, views, cached_share=0.8)
        print(views, best, mixed)

What to do next

• Measure your real clip sizes from finished jobs, not from a guess.
• Estimate views per clip for one campaign, then run the script with a pessimistic cached share.
• Compare the result with the per-clip generation cost you already see in the usage ledger at GET /v1/usage.
• Prefer linking the Sume media URL when you do not need your own domain or retention rules.

What this number leaves out

The $0.03 per GB figure covers egress only. Storage at rest, requests and any CDN or transformation features are separate lines that the entry I read does not price, so a full serving budget needs the live pricing page. The table also assumes a whole-file download per view; a player that streams only part of a clip, or a viewer who leaves early, transfers less than the full file.

A simple discipline helps: log the byte size of each clip when you store it, log the view count from your own analytics, and multiply. If the monthly total is small next to your generation spend, spend your effort elsewhere; if a few clips go viral, the cached share is the number to watch.