Anyquery: eine SQL-Schicht über Dateien, Apps und LLMs

Welches Problem Anyquery löst und für wen

Die Ausgangslage ist bekannt: Eine Frage betrifft Daten, die in einer CSV-Datei, einer SQLite-Datenbank und einem SaaS-Dienst wie Notion oder Airtable liegen. Ohne gemeinsame Abfrageschicht bleibt nur der Export in eine Tabellenkalkulation oder ein einmaliges Skript. Anyquery setzt genau dort an und beschreibt sich selbst als SQL-Query-Engine, die auf SQLite aufbaut und deren Funktionsumfang über Plugins erweitert wird. Zielgruppe sind damit weniger Plattformteams als Einzelpersonen und kleine Gruppen, die explorativ arbeiten: Analysten, die mehrere Quellen in einer Sitzung verbinden wollen, und Entwickler, die einem LLM strukturierten Zugriff auf lokale oder entfernte Daten geben möchten. Der zweite Adressatenkreis ist weniger offensichtlich. Weil Anyquery sich als MySQL-Server ausgeben kann, richtet es sich auch an Nutzer von MySQL-kompatiblen Clients wie TablePlus oder Metabase. Das README nennt diese Verbindungswege ausdrücklich, was den Anspruch erklärt: nicht ein neues Datenbanksystem, sondern eine Fassade, hinter der heterogene Quellen wie eine einzige MySQL-Instanz erscheinen.

SQLite im Kern, Plugins als Erweiterungsschicht

Der Mechanismus lässt sich aus dem Repository-Aufbau ablesen. Anyquery basiert auf SQLite und lädt Plugins, um fremde Systeme als Tabellen bereitzustellen. Die Go-Installationsanweisung macht die Abhängigkeit explizit: Der Build erfolgt mit CGO_ENABLED=1 und den Build-Tags vtable, fts5, sqlite_json und sqlite_math_functions, und das README verweist darauf, dass die Anbindung über go-sqlite3 läuft. vtable ist dabei der entscheidende Baustein: SQLite-Virtual-Table-Module erlauben es, eine externe Datenquelle hinter einer Tabellenschnittstelle zu verbergen, sodass Abfragen, Joins und Projektionen in SQL formuliert werden können. Die Plugins sind also keine Konnektoren im klassischen ETL-Sinn, die Daten vorab kopieren, sondern Schnittstellen, die während der Abfrage Werte liefern. Genau diese Unterscheidung bestimmt die Grenzen des Werkzeugs: Wer eine Quelle mit hoher Latenz oder mit Ratenlimits anbindet, merkt das an der Abfragezeit, nicht an einem nächtlichen Ladeprozess. Neben eigenen Plugins kann Anyquery laut Dokumentation auch beliebige SQLite-Erweiterungen laden, was den Umfang über die offizielle Registry hinaus öffnet.

Installation und die ersten Befehle

Das README listet mehrere Wege. Für macOS und Linux gibt es ein Skript, das die passende Binärdatei lädt, die Prüfsumme verifiziert und sie in den PATH schreibt, ohne sudo: curl -fsSL https://anyquery.dev/install.sh | sh. Über die Umgebungsvariablen ANYQUERY_VERSION und ANYQUERY_INSTALL_DIR lassen sich Version und Zielverzeichnis festlegen, ein Update erfolgt durch erneutes Ausführen desselben Befehls. Daneben stehen Paketquellen für Homebrew (brew install anyquery), APT über ein Repository unter apt.julienc.me, YUM/DNF über yum.julienc.me, sowie Scoop, Winget und Chocolatey für Windows. Bemerkenswert ist der Go-Weg: Er verlangt Go 1.26 oder neuer, weil laut README einige Abhängigkeiten ältere Versionen nicht unterstützen, und er verlangt einen C-Compiler im PATH, weil cgo zum Einsatz kommt. Das ist eine reale Hürde in schlanken CI-Images, die nur die Go-Toolchain enthalten. Für den interaktiven Einstieg genügt der Aufruf anyquery, der die Shell öffnet. Wer einen MySQL-Client bevorzugt, startet anyquery server und verbindet sich mit mysql -u root -h 127.0.0.1 -P 8070. Für LLM-Clients gibt es zwei Betriebsarten: anyquery mcp --stdio für den Start durch den Client selbst oder anyquery mcp --host 127.0.0.1 --port 8070 für einen HTTP- und SSE-Tunnel. Clients ohne MCP-Unterstützung, die aber Function Calling beherrschen, bekommen über anyquery gpt eine ID, die in der Client-Konfiguration hinterlegt wird.

Der MCP-Pfad und was er voraussetzt

Die LLM-Anbindung ist der Teil, der Anyquery von einem reinen Analysewerkzeug unterscheidet. Über das Model Context Protocol stellt der Prozess einem Client Kontext bereit, und das README zeigt beide Transportwege, stdio und HTTP mit SSE. Der stdio-Modus ist der unauffälligere: Der Client startet den Prozess, es gibt keinen offenen Port, und die Lebensdauer des Servers entspricht der Sitzung. Der HTTP-Modus mit --host 127.0.0.1 --port 8070 bindet an die Loopback-Adresse, was für lokale Werkzeuge ausreicht, aber jede Erweiterung auf andere Interfaces zu einer Entscheidung über Zugriffskontrolle macht. Hier ist das Material dünn. Das README nennt weder Authentifizierung noch Autorisierung für den MCP-Server, und die Release-Historie enthält mehrere Sicherheitskorrekturen, darunter 0.4.5 und 0.4.6 mit den Titeln Security fixes und Security fix again sowie 0.5.0 mit Sandbox strengthening. Dass drei aufeinanderfolgende Releases Sicherheitsthemen adressieren, ist ein Hinweis darauf, dass die Angriffsfläche ernst genommen wird, aber auch darauf, dass sie sich bewegt. Wer den MCP-Server über die Loopback-Grenze hinaus betreibt, sollte die Dokumentation zu den aktuellen Sandbox-Einstellungen selbst prüfen, statt sich auf die Versionsnummer zu verlassen.

Grenzen: wo Anyquery das falsche Werkzeug ist

Die Abfrage läuft im Prozess des Nutzers. Für einen einzelnen Analysten ist das ein Vorteil, für ein Team mit geteilten Dashboards ein Problem, weil jede Person ihre eigene Instanz mit eigenen Plugin-Zugangsdaten betreibt. Metabase kann sich zwar mit dem MySQL-Modus verbinden, aber die Datenhoheit bleibt beim Rechner, auf dem anyquery server läuft. Ein zweiter Punkt ist die Reproduzierbarkeit. Weil Plugins gegen Live-Systeme abfragen, kann dieselbe SQL-Anweisung zu unterschiedlichen Zeitpunkten unterschiedliche Ergebnisse liefern, ohne dass ein Ladeprotokoll existiert, das man später nachvollziehen könnte. Für Berichte mit Prüfpflicht ist das ungeeignet. Drittens die Plattformabhängigkeit: Der Go-Build benötigt cgo und einen C-Compiler, was Cross-Compilation erschwert und statische Binärdateien ausschließt, sofern man nicht auf die vorgebauten Releases zurückgreift. Und schließlich die Lizenz. Das Repository weist NOASSERTION aus, also keine von GitHub erkannte Standardkennung. Das README enthält keine Lizenzdiskussion. Wer Anyquery in ein Produkt einbetten oder weitergeben will, muss die tatsächlichen Bedingungen aus dem Repository selbst ermitteln; aus dem vorliegenden Material lässt sich dazu nichts ableiten.

Alternativen und der Unterschied im Ansatz

Der naheliegende Vergleich ist DuckDB. Beide Systeme erlauben SQL über Dateien, und beide sind in der Lage, CSV, JSON und Parquet zu lesen. Der Unterschied liegt in der Erweiterungsstrategie. DuckDB verfolgt einen In-Process-Ansatz mit eigenen Erweiterungen, die auf Spaltenformate und Vektorverarbeitung optimiert sind, und positioniert sich als analytische Engine für lokale Dateien. Anyquery setzt stattdessen auf SQLite-Virtual-Tables und ein Plugin-Modell, dessen Stärke die Anbindung von Anwendungen ist, nicht die Anbindung von Dateiformaten. Wer große Parquet-Bestände mit Aggregationen über Millionen Zeilen auswertet, wird bei Anyquery nicht die richtige Wahl treffen. Wer dagegen eine Frage wie die nach offenen Aufgaben in Notion zusammen mit einer lokalen CSV beantworten will, findet bei DuckDB keinen vergleichbaren Plugin-Pfad zu SaaS-Diensten. Ein zweiter Unterschied ist die Schnittstelle nach außen: DuckDB wird als Bibliothek oder CLI eingebettet, Anyquery kann zusätzlich als MySQL-Server auftreten und damit bestehende BI-Clients ohne eigenen Treiber bedienen. Das ist ein Architekturunterschied, keine Frage der Leistungsfähigkeit. Wer bereits eine MySQL-kompatible Analysesicht auf heterogene Quellen braucht, hat mit Anyquery einen kürzeren Weg; wer eine analytische Engine für Dateien sucht, ist mit DuckDB direkter bedient.

Wartung, Versionen und Lizenz

Die Release-Historie zeigt einen kurzen Takt: 0.4.5 im Juni 2026, 0.4.6 im Juli 2026, 0.5.0 im August 2026. Zwei dieser Releases tragen Sicherheitstitel, eines davon die Formulierung Security fix again, was auf eine schnelle Reaktion auf gemeldete Probleme hindeutet. Für Betreiber bedeutet das zweierlei. Erstens sind Updates keine seltene Angelegenheit, sondern ein regelmäßiger Vorgang, und die Update-Prozedur unterscheidet sich je nach Installationsweg: Beim Skript genügt ein erneuter Aufruf, bei APT und DNF greift der Paketmanager, bei Homebrew ebenso. Zweitens sind Versionsnummern unter 1.0 ein Signal, dass sich Schnittstellen und Plugin-Verhalten noch ändern können. Wer Plugins selbst schreibt, muss damit rechnen, dass sich die Plugin-API zwischen Minor-Versionen verschiebt. Ein Pin auf eine konkrete Version ist über ANYQUERY_VERSION möglich und für wiederholbare Abläufe sinnvoll. Zur Lizenz lässt sich aus dem Material nur sagen, dass sie als NOASSERTION ausgewiesen ist und das README dazu nichts ausführt. Das ist keine Rechtsberatung, aber es ist ein konkreter Prüfpunkt: Wer Anyquery kommerziell einsetzt oder weiterverteilt, muss die Bedingungen im Repository und in der Dokumentation selbst nachlesen, bevor er sich darauf verlässt.

Redaktionelles Fazit

Anyquery passt zu Datenanalysten und Entwicklern, die Ad-hoc-Fragen an CSV-, Parquet- oder JSON-Dateien und an Dienste wie Notion oder GitHub in einer einzigen SQL-Sitzung beantworten wollen, ohne für jede Quelle einen eigenen Export zu bauen. Wer eine dauerhaft laufende Datenplattform mit garantierten SLAs, klarer Versionspolitik und eindeutig dokumentierter Lizenz braucht, sollte zuerst die Lizenzangabe NOASSERTION und die Release-Historie prüfen und erst danach entscheiden. Vor dem ersten Einsatz würde ich konkret verifizieren, ob das gewünschte Plugin in der Registry unter anyquery.dev/integrations steht und ob die Sandbox-Härtung aus 0.5.0 den geplanten Zugriff auf lokale Dateien überhaupt zulässt.

Offizielle Quellen

1. Issues
2. julien040/anyquery on GitHub
3. Project website
4. README
5. Releases