Eidos：把 Notion 式資料庫塞進單一 SQLite 檔案
A single-file relational spreadsheet for you and your agent.
秒懂
- 它是什麼？
- Eidos File 是以標準 SQLite 為基礎的單檔格式，Eidos Lite 是操作這種檔案的桌面程式，另有 agent-first 的 CLI。它的賣點同時也是它的邊界：資料庫就是檔案，檔案就是資料庫。
- 適合誰用？
- 如果你要的是一份能直接丟進 git、能用 sqlite3 打開、又能給 agent 讀寫的關聯式資料檔，Eidos 值得先裝 CLI 試一輪：eidos create 建檔、eidos serve 開本機服務，確認欄位型別與關聯是否符合你的資料模型。若你的協作情境需要多人同時編輯同一份資料、需要細緻的權限控管，或團隊無法接受 AGPL-3.0 的傳染範圍，這個專案現在就不該進你的技術棧。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一個檔案同時是資料庫與文件
多數人做個人資料管理時會撞到同一個牆：關聯式資料庫好用，但你要先決定 schema、跑 migration、找地方託管；筆記軟體好上手，但資料被鎖在它的雲端格式裡，你沒辦法用 SQL 查它。Eidos 的解法是把兩邊壓縮成一個 .eidos 檔案。README 的定位寫得很直白：Eidos File 是「an open, single-file format built on standard SQLite」，而 Eidos Lite 是操作這種檔案、以及本機資料夾裡普通檔案的桌面程式。
目標讀者其實有兩層。第一層是不想為了一份書單、一份專案追蹤表就架資料庫的個人使用者，他們要的是 Notion 式的欄位型別、關聯與多檢視，但資料留在本機。第二層是寫 agent 或自動化流程的開發者，README 把 CLI 描述為 agent-first，並指向 apps/cli/README.md 的 agent 與自動化工作流程說明。對這一層來說，重點不是介面好不好看，而是檔案能不能被程式穩定地建立、查詢與更新。
值得注意的是 repo 的 topics 同時掛了 local-first、offline、sqlite、notion-alternative。這幾個詞放在一起，等於宣告了一個取捨：換取檔案主權的代價，是放棄雲端協作帶來的即時性。
檔案格式與 Runtime 分層，UI 另外抽套件
從 repo 結構可以看出這個專案不是單體應用。packages/eidos-file 實作 Eidos File 格式與 Runtime，packages/eidos-file-ui 提供共用的 React 編輯器介面。這個切法意味著格式的讀寫邏輯與畫面渲染是兩件事，CLI 與桌面程式理論上可以共用同一層 Runtime，而只有桌面與瀏覽器版本需要拉進 UI 套件。
更外圍是 host 層。apps/eidos-lite-desktop 是桌面程式，apps/eidos-file-web 驅動瀏覽器編輯器，apps/cli 則包含 CLI 與本機伺服器。另外有一個 apps/sqlite-web-viewer，是獨立、唯讀的 SQLite 檢視器。把它獨立出來這件事本身透露了設計意圖：即使不進 Eidos 的編輯流程，你也應該能看自己檔案裡的內容。
Markdown 的處理被拆到 packages/markdown，用 Lexical 做 WYSIWYG 編輯器，支援所謂 Eidos Flavored Markdown。README 對這層的邊界講得很清楚：Markdown 仍是 canonical value，套件負責 import、編輯、序列化、保真度檢查與外掛 API，而 persistence 與附件儲存由 host 負責。這是合理的責任劃分，但也代表如果你要自己接一個 host，附件儲存與持久化要自己寫。
版本歷史與同步不在核心裡。README 說 Eidos Lite 使用 Graft 處理本機版本歷史與選用的 Sync，而 Graft 是一個獨立發展、面向開發者的應用狀態版本控制系統。換句話說，同步不是這個 repo 自己實作的功能，而是外部依賴。這個依賴的成熟度，README 沒有給出可判斷的資訊。
從 CLI 建出第一個 .eidos 檔案
安裝方式依平台分成兩條指令。macOS 或 Linux 走 shell 腳本，Windows 走 PowerShell：
curl -fsSL https://download.eidos.space/cli/install.sh | sh
irm https://download.eidos.space/cli/install.ps1 | iex
裝完之後，README 給的建檔範例同時展示了 schema 宣告的方式：
eidos create example.eidos --table Tasks --label-field Title --fields '[{"name":"Title","type":"text"},{"name":"Status","type":"select"}]'
eidos serve example.eidos --open
這裡有幾個具體的設定鍵值得記住。--table 指定資料表名稱，--label-field 指定用哪個欄位當作記錄的顯示標籤，--fields 吃一段 JSON 陣列，每個元素有 name 與 type。範例示範了 text 與 select 兩種型別。這代表 schema 是用命令列參數直接餵進去的，不是先寫一份 migration 檔再執行。對自動化流程來說這很省事，對需要版控 schema 變更的團隊來說則是另一回事。
eidos serve 會起一個本機伺服器，--open 應該是順手打開介面。README 沒有說明這個伺服器預設綁定的位址與埠號，如果要讓同網段的其他裝置連進來，這是你必須自己查文件確認的第一件事。
不想裝東西的話，README 也提供瀏覽器路徑：打開 editor.eidos.space，直接建立或編輯本機的 .eidos 檔，無需安裝。桌面版則標明本機使用不需要帳號。
開發者要從原始碼建置的話，README 列出的需求是 Node.js 22.23.1、Corepack，以及做 CLI 工作時需要 Rust stable。流程是 corepack enable、pnpm install --frozen-lockfile，接著依目標跑 pnpm dev:eidos-lite、pnpm dev:eidos-file-web 或 pnpm dev:markdown-editor-playground。測試指令有 pnpm test:eidos-file 與 pnpm test:markdown-editor。CLI 留在自己的 Rust workspace，要進 apps/cli 目錄跑 cargo test --workspace --locked。注意 Node 版本被釘在 22.23.1，這種精確到 patch 的指定通常意味著建置對版本敏感，不要用你機器上的 LTS 版本硬上。
單檔格式換到的好處，以及換掉的東西
單檔最大的實際價值是它可以直接進 git。一般筆記軟體的資料庫是二進位 blob 或雲端 API，你沒辦法 diff、沒辦法 branch、沒辦法在合併衝突時看懂發生什麼事。Eidos File 建立在標準 SQLite 上，至少理論上你可以拿 sqlite3 指令去開它，也可以寫自己的查詢。repo 裡那個獨立的唯讀 SQLite viewer 就是這個思路的產物。
但單檔同時是硬限制。SQLite 的寫入是整庫層級的鎖，兩個行程同時寫同一個檔案會遇到鎖定問題。README 沒有描述任何多人同時編輯同一份 .eidos 檔的機制，它談的是本機版本歷史與選用的 Sync，而 Sync 由外部的 Graft 負責。這意味著協作不是這個格式現在解決的問題。如果你需要的是三個人同時改同一張表、每個人看到對方的游標，這個專案不是為那個場景設計的。
第二個限制是 schema 的演進。--fields 傳 JSON 這種做法在建檔時很方便，但當你要改欄位型別、拆表、加索引時，README 沒有給出對應的 CLI 操作。它說 CLI 可以 create、inspect、query、update、serve，inspect 與 update 的實際粒度則需要看 apps/cli/README.md 才能判斷。在確認之前，不要把 Eidos 當成需要頻繁 schema migration 的生產資料庫來規劃。
第三，附件與 Markdown 的持久化責任在 host 身上。如果你的資料表裡有圖片或長文，這些東西怎麼存、存在檔案裡還是旁邊的資料夾，README 層級的資訊不足以回答。這是採用前必須實測的部分。
與 Notion、Obsidian 的差異在哪裡
拿 Notion 來比，差別不在功能清單，而在資料的位置與查詢方式。Notion 的資料在它的伺服器上，你用它的 API，schema 由它的介面定義，協作是內建的。Eidos 把資料放在你磁碟上的一個 SQLite 檔，協作要另外接 Graft，好處是你隨時可以繞過 Eidos 直接用 SQL 讀。兩者的取捨很單純：要協作順暢就選 Notion，要檔案主權就選 Eidos，中間沒有太多模糊地帶。
拿 Obsidian 來比更接近，因為兩者都主打本機檔案。差異在資料模型。Obsidian 的核心是 Markdown 檔案加上 frontmatter，關聯靠雙向連結與 Dataview 這類外掛查詢，本質上是文件集合。Eidos 的核心是關聯式資料表，有欄位型別、有 label field、有 select 型別，本質上是資料庫。如果你的資料有明確的表格結構與跨表關聯，Eidos 的模型更貼合；如果你的資料主要是一堆互相連結的長文，Obsidian 的檔案粒度更自然。
還有一條路是自己寫。既然格式是標準 SQLite，你當然可以自己開一個 .db 檔、自己寫 schema、自己刻一個前端。Eidos 提供的價值就在 packages/eidos-file 與 packages/eidos-file-ui 這兩層已經處理好的東西，而 README 明確指出這兩個套件以 MIT 釋出。對想嵌入類似功能的開發者來說，這是比整個應用更實際的切入點。
授權拆分的實際影響
這個 repo 的授權不是單一答案。整份 repository 是 AGPL v3，但 README 明確列出可重用的 @eidos.space/eidos-file 與 @eidos.space/eidos-file-ui 兩個套件以 MIT 釋出。這種雙軌安排在開源專案裡不罕見，用意是讓格式與 UI 元件能被更寬鬆地採用，同時確保應用本體與伺服器端的修改會回饋。
實務上你必須分清楚自己碰的是哪一層。如果你的產品只是依賴 @eidos.space/eidos-file 來讀寫檔案格式，README 說這部分是 MIT。如果你是把 Eidos Lite 或 apps/cli 拿去改、拿去架成對外服務，AGPL 的網路條款就會進入討論範圍。這一段不構成法律意見，實際專案要請法務確認套件層級的 LICENSE 檔案，而不是只看根目錄那一份。
維護成本方面，README 給了幾條可觀察的線索。Node 版本被釘死在 22.23.1，CLI 是獨立的 Rust workspace，前端依賴 Lexical，版本歷史與同步依賴外部的 Graft 專案。這意味著升級時你要同時追蹤 Node、Rust toolchain 與 Graft 三個面向。從 release 命名可以看出 CLI 與 Lite 是分開發版的，lite-v0.11.0 與 cli-v1.1.0 各有自己的版本線，兩者的相容關係需要從 release notes 確認，README 沒有交代。
最後一個要自己驗證的點：README 說 CLI 可以 inspect 與 query，但沒有給範例。對 agent 工作流程來說，這兩個子命令的輸出格式決定了你能不能穩定解析，這比 create 能不能跑更重要。先讀 apps/cli/README.md，再決定要不要把 Eidos 接進你的自動化流程。
編輯結論
如果你要的是一份能直接丟進 git、能用 sqlite3 打開、又能給 agent 讀寫的關聯式資料檔，Eidos 值得先裝 CLI 試一輪：eidos create 建檔、eidos serve 開本機服務，確認欄位型別與關聯是否符合你的資料模型。若你的協作情境需要多人同時編輯同一份資料、需要細緻的權限控管，或團隊無法接受 AGPL-3.0 的傳染範圍，這個專案現在就不該進你的技術棧。動手前先確認兩件事：你的 Node 版本能否對上 22.23.1，以及 packages/eidos-file 與 packages/eidos-file-ui 的 MIT 授權是否涵蓋你真正要引用的部分，其餘仍受 AGPL 約束。
社群筆記