Why Pixeltable?

What Pixeltable replaces in a multimodal AI stack, why we built it, and when to use something else.

Pixeltable is an open-source Python library for AI apps that work on video, images, audio and documents. A table holds references to your files next to ordinary columns: a path or URL you insert stays where it is, and files you upload or Pixeltable produces go to its media store, on local disk or in your own bucket (Cloud storage). The work you want done on them, like sampling frames, transcribing audio, calling a model or embedding the result, is a column too. Insert a row and Pixeltable runs that work, stores what it produces and indexes it, with no embed-and-upsert job to run. The whole backend, from tables to HTTP routes, sits in one Python file, app.py.

The stack it replaces

Take a video search app. Users upload videos, each one gets transcribed and summarized, and you can search the summaries. Built the usual way, that’s:

• an S3 bucket for the videos, and a Postgres table for their keys and metadata
• a queue or an Airflow DAG that picks up new uploads, extracts the audio, and calls Whisper and then an LLM
• a job that embeds the summaries and writes them to a vector database
• a FastAPI app that takes uploads, queries Postgres and the vector database, and merges the results
• the scripts in between that keep all of it in sync

Each piece is fine on its own. The trouble is the joints. A video gets deleted from the bucket and its row stays behind. The DAG reruns every video because it can’t tell which ones changed, unless you write that bookkeeping yourself. The vector database keeps serving embeddings of last week’s summaries. And the first time you want to try a better prompt, you write a backfill script and hope it touches the right rows.

In most of these projects, the plumbing is most of the code, and it’s where most of the bugs are.

The same app in Pixeltable

Each of those systems becomes a few lines of app.py:

Before	In app.py
The bucket and the metadata table	A table with a video: pxt.Video column
The DAG steps	Computed columns: audio, then transcript, then summary, each one reading the one before
The embedding job and the vector database	pxt.EmbeddingIndex(summary, ...) in the table’s __indexes__
The FastAPI app	A FastAPIRouter with an insert route and a search route
The sync scripts	Nothing to write. Inserting a row runs everything that depends on it

The full file is in the README. Two commands run it: pxt schema update app.py my_app creates the table and its index, and pxt service update app.py my_app starts the service. The Quickstart walks through both with a smaller file.

What a change costs

Every computed column refers to the columns it reads, so Pixeltable knows what to run and, after a change, what to rerun. That’s the part you’d otherwise build by hand.

New uploads only cost new work, and a better prompt reruns only the summaries, not the transcripts you already paid for. Prompt changes, failed model calls and table versions all follow the same bookkeeping. When computed columns run has the details.

The same app.py runs on Pixeltable Cloud. pxt db update uploads the project to a hosted database, then the same two commands take its pxt:// URI in place of my_app, so moving isn’t a rewrite.

Why we built it

We’re database people: Pixeltable comes from the creators of Apache Parquet and Impala. When we looked at multimodal AI projects, we kept finding the same thing. The models were the interesting part, and the team spent most of its time on data plumbing.

Lovable and Bolt made web apps something one person can build, by putting a small surface over a hard problem. We wanted that for developers working with video, images, audio and documents, so we moved the work into the database. The engine tracks what depends on what, so it works out which rows to recompute. The first version of an app and its tenth revision are the same kind of work: edit app.py, run pxt schema update, then pxt service update.

One file also helps when a coding agent writes the code. The agent writes the whole backend in app.py, and you review one diff instead of a change in every system. AI coding agents covers the skill and the MCP servers.

The longer version is in Making Multimodal More Lovable.

When it’s the wrong tool

If you don’t want a schema, Pixeltable is the wrong tool. Every column has a type, and the shape of every table lives in app.py.

It isn’t a no-code builder either. You write Python, and Pixeltable is the data layer under your app. The frontend is up to you, whether that’s Lovable or your own React code calling the routes from its server.

It won’t pick your model or tell you whether the answers are any good. Video files are still big and model APIs still fail. What Pixeltable does is keep track of what ran and what needs to run again.

And if your current stack works and the glue isn’t costing you much, keep it.

If you try Pixeltable and leave, your data comes with you. Media can live in your own bucket (Cloud storage), and pxt.io.export_sql() or pxt.io.export_parquet() copies a table out whenever you want.

What you can build

RAG and live APIs

Documents split into chunks, an embedding index, and a search route, with no re-embed job when you add or remove documents.

Agents

Tool calls are columns, so every call is a row you can query later.

Media pipelines

Frames and transcripts as rows, ready to export for training.

Coming from Pinecone, Postgres, LangGraph or Airflow? Migrate shows what each one becomes.

Next

Quickstart

From an empty folder to a POST that returns computed columns, on your machine.

Pixeltable Cloud

The same app.py on a hosted database, from pxt login to a running service.

Rather start in a notebook? The 10-minute tour needs no CLI.