What It Costs to Store and Index a Video Library for Search

There is no price list for indexing a video library, because the answer depends on four decisions you have not made yet. What there is, is an arithmetic that turns those four decisions into a number. This page works it end to end for ten thousand hours of footage, with every input stated as an assumption you should replace.

The inputs, all of them assumptions

Every figure below is an assumption chosen to be plausible in mid-2026. None is a quoted price and none is a measurement. Substitute your own before quoting any total to anyone.

ASSUMED INPUTS
  library size          10,000 hours of 1080p30 footage
  source bitrate         5 Mbit/s   H.264, a typical 1080p30 delivery rate
  proxy bitrate        1.5 Mbit/s   720p copy for playback and scrubbing
  object storage       $0.021 per GB-month
  egress               $0.09  per GB
  CPU                  $0.04  per vCPU-hour
  GPU                  $1.20  per GPU-hour
  decode speed         8x realtime per vCPU for 1080p H.264
  embedding throughput 250 frames/s on one GPU
  embedding dimension  1024, float32
  mean shot length     5 s (edited content; raw footage runs far longer)

Storing the footage

Bitrate to bytes is the first conversion and the one most often done wrong by a factor of eight. A bitrate in megabits per second becomes bytes per hour by multiplying by 3,600 and dividing by 8.

5 Mbit/s x 3600 s = 18,000 Mbit per hour
18,000 / 8        =  2,250 MB per hour = 2.25 GB per hour

10,000 h x 2.25 GB      = 22,500 GB = 22.5 TB
22,500 GB x $0.021/GB-mo = $472.50 per month = $5,670 per year

720p proxy at 1.5 Mbit/s
  1.5 x 3600 / 8 = 675 MB/h = 0.675 GB/h
  10,000 h x 0.675 = 6,750 GB = 6.75 TB
  6,750 x $0.021 = $141.75 per month

thumbnails, 1 per 10 s at 40 kB
  10,000 h x 360 per hour = 3,600,000 files x 40 kB = 144 GB
  144 x $0.021 = $3.02 per month  (but 3.6 M objects of per-request cost)

storage subtotal        ~$617 per month, ~$7,400 per year

Three observations. Object counts have their own cost that byte counts hide: 3.6 million thumbnails cost almost nothing to store and generate a request bill and a listing problem. Storage class matters more than any other lever here — archival tiers cost a fraction of the figure above but carry retrieval fees and restore latency, which is fine for masters and wrong for anything a search result links to. And a library that grows keeps paying: the monthly figure is for a static corpus, and an ingest rate of a hundred hours a week adds about $2.60 a month to the bill every month, compounding into the annual number.

Decoding is the compute cost, not embedding

The intuition that indexing cost is dominated by GPU time for embeddings is, on this arithmetic, wrong. Start with how many frames you actually embed, which depends on the sampling policy far more than on the model.

SAMPLING POLICY, three options
  every frame at 30 fps   10,000 h x 3600 x 30 = 1,080,000,000 frames
  1 frame per second      10,000 h x 3600      =    36,000,000 frames
  1 frame per shot (5 s)  36,000,000 / 5       =     7,200,000 frames

EMBEDDING COMPUTE, at 250 frames/s and $1.20/GPU-hour
  36,000,000 / 250 = 144,000 s = 40.0 GPU-hours  -> $48.00
   7,200,000 / 250 =  28,800 s =  8.0 GPU-hours  -> $9.60

DECODE COMPUTE, at 8x realtime per vCPU and $0.04/vCPU-hour
  10,000 h / 8 = 1,250 vCPU-hours -> $50.00

one-off indexing subtotal, 1 fps policy   $48 + $50 = $98

Under a hundred dollars to index ten thousand hours, against roughly $7,400 a year to keep the footage. The one-off compute is about 1.3% of the first year of storage. This is the shape of the answer that surprises people, and it is robust to the assumptions being wrong by a good deal: you could be off by ten times on the GPU throughput and the conclusion would not change.

It also means the sampling policy should be chosen for retrieval quality rather than for cost. Going from one frame per shot to one frame per second costs about $38 extra across the whole library. What it buys — or fails to buy — is coverage, and keyframe extraction and shot boundary detection are how you spend that budget on the frames that carry information rather than on the ones that repeat.

The caveat on decode is that 8× realtime is a single-threaded figure for 1080p H.264 on a general-purpose core. HEVC and AV1 decode considerably slower on CPU, 4K is roughly four times the pixel rate of 1080p, and hardware decode changes the picture entirely. If your corpus is 4K HEVC, multiply the decode line and re-check whether it has become the dominant term — on that footage it usually has.

Storing the index

Vectors are small individually and there are a great many of them, and unlike the footage they generally have to be resident in memory to be searched quickly.

36,000,000 vectors x 1024 dims x 4 bytes (float32)
  = 147,456,000,000 bytes = 147.5 GB raw

HNSW graph overhead, roughly 1.3-1.6x depending on M
  147.5 x 1.5 = ~221 GB resident

7,200,000 vectors (1 per shot), same dimensions
  7.2 M x 1024 x 4 = 29.5 GB raw, ~44 GB with graph overhead

int8 scalar quantisation, 4 bytes -> 1 byte
  36 M vectors: 147.5 -> 36.9 GB raw, ~55 GB resident
   7.2 M vectors: 29.5 ->  7.4 GB raw, ~11 GB resident

Now the cost ordering inverts. Two hundred and twenty gigabytes of RAM is a substantial and permanent monthly line item, against $48 of one-off GPU time to produce what sits in it. This is the real reason to sample per shot rather than per second, and the real reason to quantise: the decision is about the index that has to stay warm, not about the compute that built it. The trade-offs are covered in vector quantization and the memory model in how HNSW works; the general cost picture is in vector storage cost.

Dimension is the other lever and it is linear. Halving the embedding dimension halves every figure in that block, and for frame retrieval a smaller dimension is often adequate — see embedding dimensions. Combining a halved dimension with int8 quantisation is an eightfold reduction, which is the difference between an index that fits on one machine and one that does not.

The cost of doing it all again

The figures above are for indexing the library once. They are not the figure you should plan around, because you will index it more than once, and the reasons are predictable enough to budget for.

The first is that embedding models are replaced. Vectors from two different models are not comparable in any way — they occupy different spaces, so a query embedded with the new model retrieves nonsense against an index built with the old one. There is no incremental migration and no partial upgrade: adopting a better embedding model means re-embedding the entire corpus, which means decoding the entire corpus again. On the assumed inputs that is the full $98, not the $48 embedding half of it, because the frames are not kept — and if you did keep every sampled frame as an image, you would be paying to store 36 million files.

The second is that the sampling policy changes. A search product that launches at one frame per shot and later discovers it needs one frame per second is doing the same full re-index, with the vector memory requirement multiplied by five. It is worth deciding early whether to keep decoded frames at a reduced resolution — 36 million frames at 20 kB as small JPEGs is 720 GB, about $15 a month on the assumed price, against $50 of decode saved on each future rebuild. That trade pays for itself after roughly three rebuilds and not before, so it depends entirely on how often you expect to change your mind.

The third is ingest. A static corpus is a convenient fiction; real libraries grow, and the incremental cost per new hour is simply the per-hour version of everything above: 2.25 GB of storage, an eighth of a core-hour of decode, and 3,600 vectors at one frame per second. Multiply by your ingest rate and add it to the monthly figure rather than treating indexing as a project that finishes.

Where the money actually goes

Collecting the derivation into one ordering, for the one-frame-per- second policy on the assumed inputs:

ANNUAL, on the stated assumptions
  vector index memory (221 GB resident)   largest, and recurring
  footage storage       $7,400/yr         second, and grows with the library
  egress, if search results play back
      1 TB/month x $0.09/GB = $92/month  = $1,100/yr
  decode                $50               one-off
  embedding             $48               one-off

The one line that catches teams out is egress. It does not appear in any indexing plan because it is not part of indexing, and then a search product that lets people play back what they found starts moving terabytes a month. At the assumed $0.09 per gigabyte, serving one terabyte a month is $1,100 a year — more than twenty times the entire one-off cost of building the index. Whether that lands on you depends on your CDN arrangement, which is exactly why it needs to be a line in the plan rather than a surprise in the invoice.