The Short Answer
Making a media library searchable has four cost centers, and most budgets only account for one. Extraction (running models over your files) dominates the first bill. Vector storage dominates the steady state once the library is large. Serving the index costs whatever keeping it queryable costs. And re-extraction, the cost of running everything again when you change an embedding model, is the one that quietly decides whether your system can ever improve.
A useful rule of thumb: extraction is a per-minute or per-page price multiplied by every feature you enable, not a single flat rate. Vector storage is pure arithmetic you can compute exactly before you spend anything: vectors x dimensions x bytes per dimension. If you only model those two, you will be close enough to make a decision, and you will avoid the two mistakes that actually hurt, which are enabling features you never query and picking an architecture where a model upgrade means paying the whole extraction bill a second time.
Why "How Much Does It Cost" Has No Single Answer
Extraction is not one operation. Every provider prices it per feature, per unit of media, and the features stack. Google Cloud Video Intelligence publishes this per-minute pricing after the first 1,000 minutes (checked July 2026):
| Feature | Price per minute |
| Label detection | $0.10 |
| Shot detection | $0.05 (free with label detection) |
| Explicit content detection | $0.10 |
| Speech transcription | $0.048 (en-US) |
| Object tracking | $0.15 |
| Text detection (OCR) | $0.15 |
| Logo detection | $0.15 |
| Face detection | $0.10 |
| Person detection | $0.10 |
| Celebrity recognition | $0.10 |
This is the single most common budgeting error in multimodal search: estimating from one feature's price, then enabling six.
Cost Center 1: Extraction
Extraction is a one-time cost per file, paid again whenever you reprocess. Three things drive it:
Which features you enable. See above. The discipline here is to enable only what you will actually query. If nobody ever searches by logo, logo detection is pure cost.
How densely you sample. For video, you are not embedding "a video", you are embedding frames. One hour at 1 frame per second is 3,600 frames. At 1 frame per 2 seconds it is 1,800. Sampling density is a direct multiplier on both extraction and storage, and the right density depends on content: a slide-based lecture needs far fewer frames than sports footage. This is covered in depth in frame sampling for embeddings.
Whether you pay for what did not change. Re-uploading a file that already exists should cost nothing. Content-hash deduplication is the mechanism, and whether your pipeline has it is worth checking before you run a backfill.
Cost Center 2: Vector Storage Is Just Arithmetic
Unlike extraction, you can compute this exactly, in advance, with no vendor input:
bytes = number of vectors x dimensions x bytes per dimension
A 768-dimension float32 embedding is 768 x 4 = 3,072 bytes, roughly 3 KB. So:
| Corpus | Vectors | float32 | int8 (4x smaller) | binary (32x smaller) |
| 1M vectors | 1,000,000 | ~3.1 GB | ~0.77 GB | ~0.10 GB |
| 10M vectors | 10,000,000 | ~31 GB | ~7.7 GB | ~1.0 GB |
| 1,000 hours of video at 1 fps | 3,600,000 | ~11 GB | ~2.8 GB | ~0.35 GB |
Quantization is the standard lever here and it is well understood: int8 typically holds retrieval quality within a point or two of float32 for most models, and binary is viable for a first-stage recall pass that a more precise stage then reranks. See embedding quantization and compression and storage tiering.
Cost Center 3: Serving the Index
Storage is what the vectors cost at rest. Serving is what it costs to keep them queryable at your latency target. The variables are index type (flat, IVF, HNSW), how much of the index must sit in memory, and your query volume. HNSW is fast and memory-hungry; IVF and on-disk variants trade latency for cost. Approximate nearest neighbor algorithms covers the tradeoff, and vector database cost comparison covers what providers charge for it.
The architectural decision that moves this number most is whether your vectors live in memory on always-on nodes or on object storage that is read on demand. The second is dramatically cheaper for large, infrequently-queried corpora, which is the case for most media archives.
Cost Center 4: Re-Extraction, the Multiplier Nobody Budgets
Here is the cost that decides whether your system can improve. Embedding models change. A better one ships roughly every few months. When you adopt it, every vector produced by the old model is invalid, because vectors from different models are not comparable.
If your architecture couples extraction to embedding, adopting a new model means re-reading your entire corpus from storage and re-paying the full extraction bill. For the 1,000-hour example below, that is another five figures. The predictable result is that teams stop upgrading, and their retrieval quality is frozen at whatever model they started with.
The mitigation is architectural, not financial: keep the expensive, model-independent extraction (decode, frame sampling, transcription, OCR) separate from the cheap, model-dependent embedding step, so a model change re-embeds cached artifacts instead of reprocessing source media. Embedding model migration without re-embedding covers the patterns, and embedding portability and versioning covers keeping both generations queryable during a cutover.
Worked Example: 1,000 Hours of Video
Assumptions stated so you can substitute your own: 1,000 hours (60,000 minutes), sampled at 1 frame per second, using published Google Video Intelligence rates from July 2026, wanting labels, speech, and on-screen text.
| Line item | Calculation | Cost |
| Label detection | 60,000 min x $0.10 | $6,000 |
| Speech transcription | 60,000 min x $0.048 | $2,880 |
| Text detection (OCR) | 60,000 min x $0.15 | $9,000 |
| Extraction subtotal | $17,880 | |
| Vector storage (3.6M vectors, 768-dim float32) | 3.6M x 3,072 bytes | ~11 GB |
| Same, int8 quantized | ~2.8 GB | |
| Re-extraction on a model change | repeat extraction subtotal | +$17,880 |
How to Cut Each Cost Center
1. Enable fewer features. Audit what users actually query. The cheapest extraction is the kind you do not run. 2. Sample less densely. Scene-aware sampling beats fixed-interval sampling: video scene segmentation explains detecting boundaries so you embed one representative frame per shot rather than one per second. 3. Quantize. int8 is close to free in quality terms for most retrieval workloads. 4. Deduplicate on content hash so a re-run pays only for what changed. 5. Decouple extraction from embedding so a model upgrade is not a full reprocess. 6. Tier storage. Most media archives are queried on a small hot subset.
Where Mixpeek Fits
Mixpeek is a multimodal data warehouse: token-level indexing and retrieval over object storage. It is relevant to this cost model in three specific ways, and they map to the cost centers above rather than to a discount.
Extraction runs against the files already in your own bucket, so you are not paying to duplicate a media library into a vendor's storage before you can search it. Extraction and embedding are separate stages, so changing an embedding model re-embeds cached artifacts instead of re-decoding source video, which is the cost-center-4 problem. And extraction output lands directly in a queryable namespace, so there is no second system to stand up and pay for before the metadata becomes searchable.
Published pricing: Managed indexing from $0.01 per document, and Build from $25/mo for up to 1M vectors. See pricing for the current tiers, MVS if you already have vectors and want agent-native search over object storage, and the feature extractors documentation for what each extractor emits and what it runs on.