[76d781175eb67bd226620976c0b2b3ac]

76d781175eb67bd226620976c0b2b3ac

问题背景

你有一个 WordPress 站点，里面存了一批书籍条目数据。现在需要：

1. 迁出 WordPress，用专门的数据库管理书籍（ISBN、作者、封面、分类、阅读状态等）
2. 保留 WordPress 做前端展示，用户能在页面上搜索/筛选书库
3. AI Agent 能直接查询，走 REST API 或 SDK，零中间层
4. 开源自托管，数据归属自己
5. 尽可能轻量（机器资源有限）

这个需求本质上是：数据库层、API 层、前端展示层、AI 对接层的四层选型问题。市面上能覆盖这四层的开源方案不多，本文逐一对比。

---

竞品全景

1. Airtable — 最省力，但不自托管

Airtable 不占用服务器资源，原生 REST API，AI Agent 可以直接 curl。WordPress 端有官方 Airtable Plugin 或 WP Data Access 桥接。

但它不是自托管的——数据在 Airtable 服务器上。如果你能接受 SaaS，它是最省心的方案；如果要求数据完全自主，跳过。

2. Supabase — 功能最全，但最重

Supabase = PostgreSQL + GoTrue + Realtime + Storage + Kong API 网关，一套 Docker 集群跑起来至少 4-6 个容器，内存占用 2-4GB。功能确实强大，PostgreSQL 自动生成 REST API，AI Agent 用 supabase-py 或直接 curl，WordPress 用 WP Data Access 直连同一份 PG。

但为了一个书库起这么一套，实在过于重了。而且这套里大部分服务（Auth、Realtime、Storage）你用不上。

3. Directus — 数据库优先，功能与资源的平衡点

Directus 的核心设计理念是”给你的数据库套一层 API + 后台管理界面”。它不是 content builder，而是 database wrapper——你建好表，它自动出 REST + GraphQL；它建的表，你也能直接用 SQL 操作。

• 单容器 + PostgreSQL，~500-600MB
• REST API + GraphQL 零配置生成
• 行级 + 字段级权限
• 内置图片裁剪/格式转换（Asset 处理）
• Extensions 体系支持 Python/Node hooks
• WP Data Access 可以直接连底层 PostgreSQL

对于 WordPress 迁移来说，Directus 有个独特优势：直接接入已有数据库。你可以把原来 WordPress 的 wp_posts 表里的书籍数据直接映射成 Directus Collection，无需导出导入。但如果你是从头新建书库，这个优势不明显。

4. NocoDB — 最轻，但对接有坑

NocoDB 定位是”开源 Airtable 替代”：可视化表格，拖拽字段，一键分享视图。

• 单容器 + SQLite，~150-300MB；或 + MySQL，~300-500MB
• REST API 自动生成
• AI Agent 走 API 没问题
• 但 WordPress 展示有坑：WP Data Access 可以直连底层 MySQL/PG，但 NocoDB 管理的是自己的 schema——它往数据库里写自己的元数据表，你的业务表 books 虽然存在，但它本质是 NocoDB 的内部表达。底层 schema 可能随版本变动，不保证前向兼容。

所以 NocoDB 建议只通过它的 REST API 对接外部系统。这意味 WordPress 前端也要走 API：自己写 shortcode 去 curl NocoDB API，或者装一个 HTTP 请求插件。不是不能做，是多了一层。

5. Strapi & Payload CMS — 传统无头 CMS

Strapi 和 Payload 是 content-first 的无头 CMS，数据被它们的 content-type builder schema 包裹。AI Agent 只能走它们定义的 API 端点，不能直连底层数据库。WordPress 展示也只能通过 API 桥接。

这两者更适合”内容编辑团队 + 前端框架”的场景，不适合”已有 WordPress 做前端、数据要高度可控”的场景。资源占用也偏高（~1GB）。

6. Trilium — 不适合

Trilium 是层级笔记工具，不是结构化数据库。没有行级权限、表格视图、Asset 处理、关系字段。WP Data Access 不能直连，Agent 只能走它的 Note API 拼凑查询。

适合做阅读笔记，不适合做书目台账。

---

对比矩阵

	Airtable	Supabase	Directus	NocoDB	Strapi
自托管	❌	✅	✅	✅	✅
资源占用	0（SaaS）	~2-4GB	~500-600MB	~150-500MB	~1GB
REST API	✅ 原生	✅ 原生	✅ 原生	✅ 原生	✅ 原生
GraphQL	❌	✅	✅	❌	✅
WP Data Access 直连	❌	✅ PG	✅ PG/Mysql	⚠️ 有风险	❌
AI Agent 对接	curl	supabase-py / curl	curl / SDK	curl	curl / SDK
已有数据库接入	❌ 导入	✅ 能接	✅ 直接映射现有表	⚠️ 建议重建	❌ 从零建
行级权限	✅	✅	✅	❌	⚠️ 有限
Asset 处理	✅ 外部	✅ Storage	✅ 内置	❌	✅ Upload
迁移难度（从 WP）	中（CSV）	低（CSV→PG）	低（直连/CSV）	中（CSV→NocoDB）	中（CSV→Strapi）

---

结论与推荐

场景一：最轻量 + 可接受 API 桥接前端

NocoDB + SQLite（~150MB）做数据库，AI Agent 走 REST API，WordPress 端自己写 shortcode curl NocoDB API 展示。最省资源，但 WordPress 展示需要开发量。

场景二：平衡 + WordPress 前端直连

Directus + PostgreSQL（~500MB）做数据库，WP Data Access 直连底层 PG 做前端，AI Agent 走 Directus REST API。资源尚可，前后端对接最顺畅，数据最可控。

场景三：功能最大化

Supabase（~2-4GB）一整套，未来如果要用 Auth、Realtime、Storage 不需要再加组件。但为了一个书库起这么一套，通常过度。

我的推荐

你的核心痛点是：WordPress 前端查询 + AI Agent 查询 + 轻量自托管。

这三个条件同时满足的最优解是 Directus + PostgreSQL + WP Data Access。WP Data Access 直连同一份 PG 数据库做前端搜索/筛选，AI Agent 走 Directus REST API，两边的数据是同一份——不存在同步问题，不存在中间层。

NocoDB 虽然比 Directus 轻，但数据通过 API 隔离、底层 schema 不可靠，把这个差值填回来了。如果你机器确实紧张到 500MB 都挤不出来，那就 NocoDB + 前端手写 REST 桥接。

实际搭建步骤（Directus 方案）

1. Docker 起 Directus（官方 compose 文件，改个端口和密码）
2. Wordpress 导出书籍 CSV，直接导入底层 PostgreSQL
3. Directus 自动识别出 Collections 和 REST API
4. WordPress 装 WP Data Access 插件，直连同一份 PG 数据库，用 Shortcode 做前端搜索/筛选/列表展示
5. AI Agent 通过 curl $DIRECTUS_URL/items/books?filter 查询

整个链路：一份 PG 数据 → Directus API（Agent）+ WP Data Access（WordPress），零冗余，零同步成本。