VideoRAG: Where Pixeltable Stores Frames and Indexes
All Stories
2026-07-203 min read
VideoRAGEmbedding IndexesStoragePixeltableVector SearchCLIPMultimodal RAGframe_iterator

VideoRAG: Where Pixeltable Stores Frames and Indexes

VideoRAG does not need a separate vector DB. Frames, embeddings, and indexes live under PIXELTABLE_HOME—here is what is on disk vs in Postgres.

Pierre Brunelle

Pierre Brunelle

Pixeltable Team

Summary: In a Pixeltable VideoRAG stack, the “vector index” is an embedding index on a column—not a separate Pinecone/Weaviate deployment. Catalog metadata and index bookkeeping live in embedded Postgres under PIXELTABLE_HOME; frames and derived media live in the media store / cache. This post maps the pieces you create in code to paths on disk.

What People Mean by VideoRAG#

Typical pattern:

  1. Store videos in a table
  2. Create a view of frames with frame_iterator
  3. Add an embedding index (CLIP on frames, sentence embeddings on transcripts)
  4. Query with column.similarity(...) for retrieval-augmented answers

Full pipeline recipes: video intelligence tutorial, video similarity search, skill reference video-rag-agents.

Minimal Pipeline#

python

Where Things Live on Disk#

Default home: ~/.pixeltable (override with PIXELTABLE_HOME). See storage architecture and Docker volumes.

ArtifactWhat it isWhere
Tables / views / schemaCatalog + column defs$PIXELTABLE_HOME/pgdata (embedded Postgres)
Embedding indexesVector index metadata + vectors managed by PixeltableTied to the catalog under PIXELTABLE_HOME (not a separate SaaS vector DB)
Source videosPaths/URLs you insertedRemain at their original location (referenced, not necessarily copied)
Extracted frames / generated mediaMaterialized media Pixeltable produces$PIXELTABLE_HOME/media (or cloud media destinations)
Remote URL downloadsCached originals$PIXELTABLE_HOME/file_cache
HF / Torch model weightsCLIP etc. downloadsHugging Face / Torch caches (e.g. ~/.cache/huggingface), not inside the table

You Do Not Need a Separate Vector Database#

add_embedding_index keeps indexes synchronized as rows are inserted or deleted—same incremental story as computed columns. Comparisons: Pixeltable vs Pinecone, incremental embedding indexes.

Views, FPS, and Storage Growth#

  • fps=0.5 ≈ one frame every two seconds—fewer rows, smaller indexes, coarser search.
  • fps=1 or higher → denser retrieval, more media and embedding storage.
  • Views are declarative: Pixeltable stores view definitions and computed results; you do not manually dump every frame to a folder unless you export.

On a Mac, Where Do I Look?#

bash

If you run inside Docker, look inside the mounted volume (often /data/pixeltable), not your host home directory.

FAQ#

What is the vector index in VideoRAG?#

An embedding index on a Pixeltable column (e.g. frames.frame), queried via .similarity().

If I delete PIXELTABLE_HOME, is the index gone?#

Yes—the catalog, indexes, and local media store are gone. Source video files elsewhere on disk remain.

Can indexes live only in S3?#

Generated media can use cloud destinations; the catalog/pgdata still needs a persistent local (or PVC) home. See infrastructure docs.

See Also#

Ready to Build?

Declarative. Multimodal. Incremental.

Focus on innovation, not infrastructure.