Eidos: eine relationale Tabelle in einer einzigen SQLite-Datei
A single-file relational spreadsheet for you and your agent.
Auf einen Blick
- Was ist das?
- Eidos bündelt eine relationale Tabellenoberfläche, einen Markdown-Editor und ein CLI in einem Dateiformat auf SQLite-Basis. Der Ansatz ist lokal-first und richtet sich an Workflows mit Agenten, doch die Lizenz und die junge Infrastruktur verlangen eine bewusste Prüfung vor der Übernahme.
- Für wen ist es gedacht?
- Eidos passt zu Entwicklern und kleinen Teams, die lokale Datensätze mit Agenten oder Skripten bearbeiten wollen und eine einzelne Datei als Übergabepunkt schätzen. Wer eine gehostete Mehrbenutzerdatenbank mit Rollen und Rechteverwaltung braucht, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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
Welches Problem Eidos löst und für wen
Wer heute strukturierte Daten lokal halten will, landet meist bei zwei unbefriedigenden Optionen. Eine klassische Datenbank trennt Schema, Oberfläche und Export. Ein Notizwerkzeug mit Tabellenansicht opfert dagegen die Abfragbarkeit. Eidos setzt genau an dieser Lücke an: Das Projekt beschreibt sich selbst als eine relationale Tabelle in einer einzigen Datei, gedacht für den Nutzer und dessen Agenten. Die Dateiendung lautet .eidos, das Format baut laut README auf Standard-SQLite auf.
Die Zielgruppe lässt sich aus der Repository-Struktur ablesen. Es gibt eine Desktop-Anwendung, einen Browser-Editor unter editor.eidos.space und ein CLI, das als agent-first beschrieben wird. Dazu kommen die Pakete packages/eidos-file für Format und Runtime sowie packages/eidos-file-ui für die gemeinsame React-Oberfläche. Wer also Datenbestände wie eine persönliche Bibliothek pflegt, Beziehungen zwischen Feldern braucht und diese Daten sowohl von Hand als auch per Skript bearbeiten möchte, gehört zur anvisierten Nutzergruppe. Ein reiner Tabellenkalkulationsersatz ist es nicht: Die Oberfläche spricht von typisierten Feldern, Relationen und mehreren Ansichten, nicht von freien Zellformeln.
Wie das Format und die Runtime zusammenspielen
Der Kern liegt in packages/eidos-file. Dieses Paket implementiert das Dateiformat und die Runtime, also die Schicht, die eine .eidos-Datei liest und schreibt. Da das Format auf SQLite basiert, ist die Persistenz kein proprietärer Blob, sondern eine Datenbankdatei. Das ist der entscheidende Unterschied zu Anwendungen, die ihre Daten in einem internen Format ablegen und einen Export nur als Zusatzfunktion anbieten.
Darüber liegt packages/eidos-file-ui als gemeinsame React-Oberfläche. Desktop-App und Browser-Editor teilen sich diesen Code, was erklärt, warum beide Umgebungen dieselben Ansichten und Feldtypen anbieten können. Ein dritter Baustein ist packages/markdown, ein Lexical-basierter WYSIWYG-Editor für Eidos Flavored Markdown. Das README ist hier bemerkenswert präzise: Markdown bleibt der kanonische Wert, das Paket übernimmt Import, Bearbeitung, Serialisierung und Prüfungen der Formatierungstreue. Persistenz und Anhänge liegen dagegen beim jeweiligen Host. Diese Trennung ist bewusst gewählt und macht das Markdown-Paket unabhängig von der Speicherschicht.
Für lokale Versionshistorie und optionalen Sync verweist das README auf Graft, ein separates Versionskontrollsystem für Anwendungszustand, das im Repository eidos-space/graft entwickelt wird. Eidos Lite bringt also eine eigene Historie mit, statt auf Git oder Dateisystem-Snapshots zu setzen.
Installation und erste Schritte über das CLI
Das CLI lässt sich auf macOS und Linux per Shell-Skript installieren:
curl -fsSL https://download.eidos.space/cli/install.sh | sh
Für Windows PowerShell gibt das README den entsprechenden Einzeiler mit irm und iex an. Danach erzeugt ein Aufruf eine neue Datei samt Tabelle und Feldern:
eidos create example.eidos --table Tasks --label-field Title --fields '[{"name":"Title","type":"text"},{"name":"Status","type":"select"}]'
eidos serve example.eidos --open
Zwei Dinge fallen auf. Erstens wird das Schema direkt auf der Kommandozeile als JSON übergeben, inklusive Feldnamen und Typen wie text und select. Zweitens gibt es mit --label-field eine Angabe, welches Feld einen Datensatz in der Oberfläche repräsentiert. Das ist ein Detail, das in vielen Datenwerkzeugen fehlt und hier offenbar Teil des Modells ist.
Für die lokale Entwicklung nennt das README Node.js in der Version 22.23.1, Corepack und Rust stable für die CLI-Arbeit. Die Befehle lauten corepack enable, dann pnpm install --frozen-lockfile. Anschließend stehen Skripte wie pnpm dev:eidos-lite, pnpm dev:eidos-file-web und pnpm test:eidos-file bereit. Die CLI selbst wird in einem eigenen Rust-Workspace entwickelt, dort gilt cargo test --workspace --locked. Wer das Projekt produktiv einsetzen will, sollte diese Versionsangaben ernst nehmen: Node.js 22.23.1 ist eine sehr konkrete Bindung.
Wo Eidos an Grenzen stößt
Die wichtigste Einschränkung steckt bereits im Namen: eine Datei. Wer mehrere Personen gleichzeitig auf denselben Daten arbeiten lassen will, braucht einen Server, Transaktionskontrolle und eine Rechteverwaltung. Das README nennt Sync als optionale Funktion über Graft, beschreibt aber keine Rollen oder Zugriffsbeschränkungen. Für kollaborative Mehrbenutzer-Szenarien ist das ein offener Punkt, den man vor einem Einsatz klären muss.
Ein zweites Problem ist die Dokumentationslage außerhalb des Repositorys. Das README verweist für Details auf die Dokumentationsseite und auf normative Spezifikationen unter docs/specs. Wer wissen will, wie Relationen intern abgebildet werden, welche SQLite-Version vorausgesetzt wird oder wie Konflikte beim Sync aufgelöst werden, muss diese Quellen selbst auswerten. Aus dem vorliegenden Material lässt sich das nicht beantworten.
Schließlich ist da die Frage der Zielumgebung. Eidos Lite ist eine Desktop-Anwendung, der Browser-Editor arbeitet laut Beschreibung mit lokalen Dateien, und das CLI bedient Automatisierung. Wer eine gehostete API mit garantierter Verfügbarkeit sucht, wird hier nicht fündig. Das Projekt positioniert sich ausdrücklich lokal-first.
Der Unterschied zu Notion, Airtable und direktem SQLite
Die Topics des Repositorys nennen notion-alternative, und der Vergleich ist naheliegend, aber die Mechanismen unterscheiden sich grundlegend. Notion und Airtable halten Daten auf ihren Servern. Der Nutzer bekommt eine Oberfläche und eine API, aber keine Datei, die er ohne den Anbieter öffnen kann. Eidos dreht das um: Die Daten liegen als .eidos-Datei dort, wo der Nutzer sie ablegt. Kein Konto ist laut README für die lokale Nutzung erforderlich.
Interessanter ist der Vergleich mit direktem SQLite-Zugriff. Technisch liegt darunter dieselbe Datenbank, aber Eidos liefert darüber eine Schicht mit typisierten Feldern, Select-Optionen, Relationen, mehreren Ansichten und einer Label-Feld-Konvention. Wer ohnehin nur mit SQL arbeitet, für den ist diese Schicht zusätzlicher Ballast. Wer dagegen ein Schema definieren, es in einer Oberfläche bearbeiten und gleichzeitig per CLI ansprechen will, spart sich den Bau dieser Zwischenschicht.
Für reine Leseaufgaben gibt es im Repository übrigens ein eigenes Werkzeug: apps/sqlite-web-viewer, einen eigenständigen, schreibgeschützten SQLite-Betrachter. Das deutet darauf hin, dass die Autoren zwischen Bearbeitung und Inspektion trennen.
Wartung, Releases und Lizenz
Die Release-Kadenz wirkt aktiv. Innerhalb weniger Tage im September 2026 erschienen lite-v0.11.0, lite-v0.10.1 und cli-v1.1.0. Zwei Versionslinien werden getrennt geführt: Eidos Lite als Desktop-App und das CLI. Wer das CLI in eine Pipeline einbaut, sollte diese Trennung beachten, denn die Versionsnummern entwickeln sich unabhängig.
Lizenzrechtlich ist das Projekt zweigeteilt. Das Repository insgesamt steht unter AGPL v3. Die wiederverwendbaren Pakete @eidos.space/eidos-file und @eidos.space/eidos-file-ui werden dagegen unter MIT veröffentlicht. Für Integratoren ist das der relevanteste Punkt: Wer nur diese beiden Pakete einbindet, bewegt sich im MIT-Rahmen. Wer die Desktop-Anwendung oder das CLI weiterverbreitet oder als Netzwerkdienst anbietet, muss die Bedingungen der AGPL prüfen. Das ist keine Rechtsberatung, sondern ein Hinweis auf die im README dokumentierte Aufteilung.
Ein weiterer Kostenfaktor ist die Rust-Abhängigkeit für CLI-Arbeit. Das README nennt Rust stable als Voraussetzung, und der CLI-Code liegt in einem eigenen Cargo-Workspace. Wer das CLI aus Quellen bauen will, braucht also beide Toolchains, Node.js und Rust.
Für wen sich der Einstieg lohnt
Das Projekt ist dann sinnvoll, wenn Daten lokal bleiben sollen und ein Agent oder Skript denselben Bestand bearbeiten soll wie ein Mensch. Die Kombination aus create mit JSON-Schema, serve zum lokalen Bereitstellen und einem Dateiformat auf SQLite-Basis deckt genau diesen Ablauf ab. Auch das Markdown-Paket ist für diesen Fall interessant, weil es Markdown als kanonischen Wert behandelt und die Formatierungstreue prüft, statt Markdown nur als Export zu erzeugen.
Wer dagegen eine Datenbank mit Nebenläufigkeit, Zugriffskontrolle und Betriebsgarantien braucht, sollte bei einem Server-System bleiben. Ebenso wenig geeignet ist Eidos für Teams, die ihre Daten nicht als Datei verteilen können oder wollen.
Vor dem ersten produktiven Einsatz sind drei Dinge zu klären: ob die AGPL-3.0-Bedingungen für die geplante Verbreitung akzeptabel sind, ob die MIT-lizenzierten Pakete allein den Integrationsbedarf decken, und wie sich das .eidos-Format gegenüber einem direkten Zugriff auf die zugrunde liegende SQLite-Datei verhält. Die Antwort auf die dritte Frage steht in docs/specs, nicht im README.
Redaktionelles Fazit
Eidos passt zu Entwicklern und kleinen Teams, die lokale Datensätze mit Agenten oder Skripten bearbeiten wollen und eine einzelne Datei als Übergabepunkt schätzen. Wer eine gehostete Mehrbenutzerdatenbank mit Rollen und Rechteverwaltung braucht, ist hier falsch. Vor der Übernahme sollte man prüfen, ob die AGPL-3.0-Bedingungen zum eigenen Vertriebsmodell passen, ob die MIT-lizenzierten Pakete @eidos.space/eidos-file und @eidos.space/eidos-file-ui den eigenen Anwendungsfall abdecken und wie sich das Format gegenüber einem direkten SQLite-Zugriff verhält.
Community-Notizen