Pixeltable: Tabellen, berechnete Spalten und HTTP-Routen in einer Python-Datei
The unified multimodal backend for AI data apps. Database, orchestration, and serving in one Python file.
Auf einen Blick
- Was ist das?
- Pixeltable bündelt Datenbank, Verarbeitung und Serving in einem App-File. Das Modell deklariert Tabellen als Klassen, Transforms als berechnete Spalten. Wer schon eine Pipeline aus Objektspeicher, Vektorindex und Endpoint-Code betreibt, sollte die Grenzen kennen, bevor er wechselt.
- Für wen ist es gedacht?
- Pixeltable passt zu Teams, die multimodale Daten und ihre Ableitungen in einer Python-Datei halten wollen und FastAPI-Routen daraus generieren lassen. Wer eine reine Vektorsuche über bereits vorhandene Postgres-Daten braucht, sollte bei pgvector bleiben: Pixeltable bringt ein eigenes Katalog- und Speichermodell mit, das sich nicht als dünne Schicht über eine bestehende Datenbank legen lässt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Aufgabe Pixeltable übernimmt und für wen
Der Ausgangspunkt ist eine wiederkehrende Aufteilung: Bilder, Videos, Audio und Dokumente liegen in einem Objektspeicher, die Embeddings in einer Vektordatenbank, die Verarbeitungsschritte in einem Orchestrator, und dazwischen liegt Endpoint-Code, der Werte von einem System ins andere kopiert. Das README beschreibt Pixeltable als Zusammenlegen dieser vier Teile in eine Anwendungsdatei: "Object storage, a vector database, an orchestrator, and the endpoint code that copies between them collapse into one application file."
Angesprochen sind damit Entwickler, die eine multimodale Anwendung bauen und keine Lust haben, vier Zuständigkeiten getrennt zu betreiben. Das README nennt als Anwendungsfälle Medienverarbeitung und RAG. Ein Team, das nur Text in eine Vektordatenbank schreibt und per SQL abfragt, gewinnt hier wenig: Der Nutzen entsteht erst, wenn Ableitungen aus Bild-, Video- oder Audiodaten mit denselben Tabellenoperationen behandelt werden sollen wie die Rohdaten.
Tabellen als Klassen, Transforms als berechnete Spalten
Das Modell ist deklarativ. Im Beispiel aus dem README erzeugt `pxt.model_base()` eine Basisklasse, von der eine Tabelle erbt. Felder mit Annotation wie `doc_id: pxt.Int` oder `title: pxt.String` sind Werte, die eingefügt werden. Zuweisungen sind berechnete Spalten: `title_upper = pxtf.string.upper(title)` läuft laut README beim Insert und beim Update, und `summary = excerpt(title)` ruft eine Funktion auf, die dieselbe Datei mit `@pxt.udf` als Python-Funktion registriert hat.
Das ist der eigentliche Mechanismus. Eine Zeile einzufügen löst die Kette darunter aus, ohne dass ein separater Job angestoßen wird. Wer aus einer Bildspalte eine Ableitung berechnet, schreibt wieder eine Zuweisung, nur mit einem anderen Spaltentyp wie `pxt.Image` oder `pxt.Video`. Indizes sind ebenfalls Deklarationen, und das README behauptet dasselbe für HTTP-Routen.
Der Preis dieser Kürze ist, dass Rechenarbeit an das Schreiben von Zeilen gebunden ist. In dem Moment, in dem ein Insert einen Modellaufruf auslöst, hängt die Latenz des Inserts an der Latenz des Modells. Das README geht auf diese Frage nicht ein.
Vom Schema zur laufenden HTTP-Schnittstelle
Die CLI trennt zwei Schritte, die man leicht verwechselt. `pxt schema update app.py my_app` legt den Katalog und die Tabellen an, startet aber kein HTTP. `pxt service update app.py my_app` startet HTTP, legt aber keine Tabellen an. Beide Befehle sind im README ausdrücklich so gegeneinander abgegrenzt.
Die Routen entstehen im selben File. Ein `FastAPIRouter` aus `pixeltable.serving` bekommt mit `add_insert_route` einen POST-Pfad, der Zeilen einfügt und die berechneten Spalten zurückgibt, und mit `add_compute_route` einen Pfad, der nur rechnet. Im Beispiel liest `pxt service list --json` den zugewiesenen Port aus, und der Aufruf erfolgt dann per curl gegen die so ermittelte URL. Den Port fest zu verdrahten wäre ein Fehler, weil er zugewiesen wird.
Wer die Routen nicht will, kann sie weglassen: Das README nennt den Weg, nur `pxt schema update` zu fahren, aus Python einzufügen und danach `export_sql` zu nutzen. Für bestehende FastAPI-Anwendungen gibt es `app.include_router(...)`.
Der Wechsel zwischen lokalem Betrieb und Cloud
Dieselbe Datei läuft laut README auch auf Pixeltable Cloud, das sich im Limited Beta befindet. Der Ablauf unterscheidet sich in drei Punkten: ein API-Key aus dem Cloud-Dashboard wird als `PIXELTABLE_API_KEY` gesetzt, die Datenbank wird in `pixeltable.toml` benannt, und die Befehle zielen über eine URI wie `pxt://org:mydb` statt über einen lokalen Namen.
Dabei gibt es zwei Einschränkungen, die man vor dem Umstieg kennen sollte. `pxt db update pxt://org:mydb` legt die gehostete Datenbank an oder aktualisiert sie, fügt aber keine Zeilen ein. Und `pxt service run` ist ausdrücklich lokal und kann Cloud nicht ansprechen. Wer eine lokale Serving-Konfiguration hat und sie unverändert gegen Cloud richten will, wird an dieser Stelle scheitern.
Für den Cloud-Betrieb gilt zusätzlich, dass er als Limited Beta ausgewiesen ist. Das ist kein Merkmal der Bibliothek unter Apache-2.0, sondern ein separates Angebot mit eigenem Zugang.
Was die Dokumentation offen lässt
Mehrere Fragen, die vor einem Einsatz wichtig wären, beantwortet das vorliegende Material nicht. Zur Speicherung steht nur, dass ein Katalog angelegt wird. Ob die Daten am Ende in einer Datei, in Postgres oder in einem Objektspeicher liegen, geht aus dem README nicht hervor, obwohl `postgres` zu den Topics des Repositories gehört. Wer die Daten später mit bestehenden SQL-Werkzeugen auswerten will, muss das selbst in der Dokumentation prüfen.
Auch zur Fehlerbehandlung fehlt jede Aussage. Wenn ein Insert eine Kette berechneter Spalten auslöst und ein Modellaufruf darin fehlschlägt, ist unklar, ob die Zeile geschrieben wird, ob die Berechnung wiederholt wird und wie ein Teilergebnis aussieht. Das ist keine Kleinigkeit, weil die Berechnung an das Schreiben gekoppelt ist.
Und die Versionierung ist ein Punkt für sich. Die Releases folgen dicht aufeinander, im Material sind drei Veröffentlichungen innerhalb von acht Tagen dokumentiert. Das README warnt sogar vor veralteten Coding-Agents: Wer `create_table` im Anwendungscode sieht, hat eine alte Skill-Version installiert und soll neu installieren. Eine solche Warnung deutet darauf hin, dass sich die empfohlene Schreibweise zwischen Versionen verschiebt.
Der Unterschied zu Postgres mit pgvector
Die naheliegende Alternative ist eine bestehende relationale Datenbank mit einer Vektor-Erweiterung, üblicherweise Postgres mit pgvector. Der Ansatz unterscheidet sich in der Zuständigkeit für die Ableitung. In Postgres speichert man das Ergebnis eines Modellaufrufs als Spalte, und ein Trigger oder ein externer Job füllt sie. Die Datenbank weiß nichts über das Modell, sie kennt nur den Vektor.
Pixeltable zieht diese Grenze anders: Die Ableitung ist Teil des Schemas. Eine berechnete Spalte beschreibt, wie ein Wert entsteht, nicht nur, dass er existiert. Das ist der Grund, warum dieselbe Datei auch die HTTP-Routen enthalten kann. Der Vorteil liegt bei Anwendungen, in denen sich die Ableitungslogik häufig ändert und man nicht will, dass Trigger und Anwendungscode auseinanderlaufen.
Der Nachteil liegt beim Bestand. Eine gewachsene Postgres-Installation mit Rechten, Backups und Auswertungen lässt sich nicht dadurch weiterverwenden, dass man Pixeltable darüberlegt. Wer vor allem eine Vektorsuche über bereits vorhandene Daten braucht, für den ist die Erweiterung die kleinere Änderung.
Wartung, Lizenz und der Blick auf die Version
Der Code steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Das ist eine allgemeine Einordnung, keine Rechtsberatung; wer den Code weiterverbreitet, sollte die Bedingungen selbst prüfen, insbesondere die Patentklausel, die Apache-2.0 von permissiven Lizenzen ohne eine solche Klausel unterscheidet.
Für die Wartung ist die Kopplung an die CLI der kritische Punkt. Der empfohlene Weg führt über `app.py` und `pxt schema update`. Ältere Schreibweisen mit `pxt.create_table()` existieren laut README weiter in Notebooks und Tests, gelten aber nicht mehr für Anwendungen. Ein Upgrade kann damit nicht nur eine Bibliotheksversion betreffen, sondern die Form des Anwendungscodes selbst.
Vor einem Upgrade empfiehlt sich ein konkreter Test: `pxt schema update app.py my_app` gegen eine Kopie der Daten laufen lassen und prüfen, ob die berechneten Spalten dieselben Werte liefern wie zuvor. Danach `pxt service list --json` aufrufen, weil der Port zugewiesen wird und sich ändern kann. Ob ein Rollback nach einem Schema-Update möglich ist, sagt das Material nicht.
Redaktionelles Fazit
Pixeltable passt zu Teams, die multimodale Daten und ihre Ableitungen in einer Python-Datei halten wollen und FastAPI-Routen daraus generieren lassen. Wer eine reine Vektorsuche über bereits vorhandene Postgres-Daten braucht, sollte bei pgvector bleiben: Pixeltable bringt ein eigenes Katalog- und Speichermodell mit, das sich nicht als dünne Schicht über eine bestehende Datenbank legen lässt. Vor dem ersten produktiven Einsatz ist `pxt schema update app.py my_app` gegen eine Kopie der Daten zu fahren und danach `pxt service list --json` zu prüfen, weil der Port zugewiesen wird und nicht fest verdrahtet werden darf.
Community-Notizen