Eidos: A single-file relational spreadsheet that treats SQLite as the document
A single-file relational spreadsheet for you and your agent.
At a glance
- What is it?
- Eidos wraps a relational spreadsheet and an agent-friendly CLI around a single SQLite file. The core judgement: it is a useful local-first data format, but AGPL licensing and a young ecosystem demand verification before adoption.
- Who is it for?
- Adopt Eidos if you want a local-first, agent-accessible relational data store where the file is plain SQLite and you accept the AGPL for the main app. Do not adopt it if you need a multi-user server, a mature plugin ecosystem, or permissive licensing for the desktop application.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Eidos actually is
Eidos is not another Notion clone bolted onto a database. It is a format first: an open, single-file format built on standard SQLite, plus tools to work with that format. The README names two layers. Eidos File is the format and runtime. Eidos Lite is the desktop app that reads and writes Eidos Files alongside ordinary files in a local folder. There is also a browser editor and a CLI. The pitch is that your data lives in one file you can query with SQL, and your agent can drive it through a command-line interface. The target user is someone who wants the structure of a relational database with the ergonomics of a spreadsheet, and who wants that data to stay on their machine by default. No account is required for local use, which is a meaningful distinction from the hosted Notion-style tools this often gets compared to.
The single-file mechanism and the relational model
The core design choice is that the spreadsheet is relational, not a flat grid. You define tables with typed fields, and you can create relations between them. The README shows a personal library example with typed fields, relations, and multiple views. That is a spreadsheet that behaves like a mini database. The file itself is standard SQLite, which means every row, relation, and view definition lives inside a format that other SQLite tooling can open. The repository splits the implementation into packages: eidos-file implements the format and runtime, eidos-file-ui provides the React editor UI, and markdown handles a Lexical-based WYSIWYG editor where Markdown remains the canonical value. The separation matters. The format package is MIT-licensed, so the core data layer is reusable without the AGPL constraints that cover the rest of the repository.
Getting it running: desktop, browser, and CLI
There are three entry points, and the README gives concrete commands for each. For desktop, you download Eidos Lite from the project site and point it at a local folder. For browser, you open editor.eidos.space to create or edit a local .eidos file without installing anything. The CLI installs on macOS or Linux with a curl pipe: curl -fsSL https://download.eidos.space/cli/install.sh | sh. Windows uses a PowerShell equivalent: irm https://download.eidos.space/cli/install.ps1 | iex. Once installed, you create a file with eidos create example.eidos --table Tasks --label-field Title --fields '[{"name":"Title","type":"text"},{"name":"Status","type":"select"}]'. Then you serve it locally with eidos serve example.eidos --open. The CLI is the agent-facing surface. It can create, inspect, query, update, and serve Eidos Files, which makes it plausible as a tool for automation scripts that need a structured data store.
The local version history and sync story
Eidos Lite uses a separate project called Graft for local version history and optional Sync. Graft is described as an independent, developer-facing version-control system for application state. This is a notable architectural decision. Instead of building sync into the Eidos file format itself, the desktop app delegates it to an external system. That keeps the file format simple, but it also means the versioning guarantees depend on a project that is not part of the Eidos repository. The README points to Graft as a dependency, not as a package in this repo. For an engineer evaluating Eidos, the question is whether Graft's maturity matches your need for history and multi-device sync. The README does not specify what happens to version history if you stop using Graft, or whether the .eidos file alone carries full history. That is a gap you would need to verify in the Graft repository before relying on it.
Where Eidos is the wrong tool
Eidos is explicitly local-first. There is no mention of a built-in multi-user server, real-time collaboration, or role-based access control. If your team needs several people editing the same data concurrently from different locations, Eidos as described is not that tool. The browser editor works on a local file, which implies you are responsible for sharing or syncing that file. The CLI serves files, but the README does not describe authentication or concurrent write handling beyond what SQLite itself provides. Another limitation is the dependency on Node.js 22.23.1, Corepack, and Rust stable for development. That is a heavy toolchain for what is ultimately a spreadsheet format. If you want a simple embedded database that a non-technical user can edit, Eidos requires the desktop app or the browser editor, not just the file. The AGPL license on the main repository also matters. If you plan to embed Eidos in a proprietary product, the AGPL terms apply to the desktop app and CLI, though the eidos-file and eidos-file-ui packages are MIT. You need to read the license carefully and decide which parts you actually depend on.
Alternatives and how they differ
The closest alternative is Airtable, which also offers a relational spreadsheet with typed fields and multiple views. The difference is fundamental: Airtable is a hosted service where your data lives on their servers, and the schema is managed through a proprietary web API. Eidos puts the entire database in a single SQLite file on your disk. That changes data ownership, offline behavior, and the way you query the data. A second alternative is a plain SQLite database with a tool like Datasette for browsing. That approach gives you the same underlying storage but no spreadsheet UI and no typed-field layer. Eidos adds the relational spreadsheet abstraction on top of SQLite, which is exactly what a bare database lacks. A third alternative is NocoDB, which is an open-source Airtable alternative that runs as a web application over a database. NocoDB requires a server and a separate database engine. Eidos does not. The trade-off is that NocoDB gives you a hosted, multi-user experience out of the box, while Eidos gives you a file you can carry around.
Maintenance, upgrade cost, and license implications
The repository is active, with recent releases in September 2026 for both the Lite app and the CLI. The development setup requires a specific Node version and Rust for CLI work, which raises the barrier for contributors. The test commands are clear: pnpm test:eidos-file and pnpm test:markdown-editor for the TypeScript packages, and cargo test --workspace --locked inside apps/cli. The presence of a normative specification in docs/specs is a good sign for stability, but the format is still young. Upgrade cost depends on how much you build around the .eidos file format. If you only use the desktop app, upgrades are routine. If you write scripts against the CLI or embed the eidos-file package, you must track changes to the format specification. The license split is unusual: the repository is AGPL v3, but the reusable packages @eidos.space/eidos-file and @eidos.space/eidos-file-ui are MIT. That means the core format logic is permissively licensed, while the app and CLI remain copyleft. You should verify which artifacts you actually distribute and which license applies to each.
Editorial conclusion
Adopt Eidos if you want a local-first, agent-accessible relational data store where the file is plain SQLite and you accept the AGPL for the main app. Do not adopt it if you need a multi-user server, a mature plugin ecosystem, or permissive licensing for the desktop application. Before committing, verify the Eidos File specification against your data portability needs, test the CLI on your platform, and confirm that the MIT-licensed packages cover the parts you plan to reuse. The project is active, but its value rests on the stability of a format that is still young.
Community notes