自托管书籍数据库选型：WordPress 迁移、Agent 对接与前端展示
问题背景
你有一个 WordPress 站点，里面存了一批书籍条目数据。现在需要：
- 迁出 WordPress，用专门的数据库管理书籍（ISBN、作者、封面、分类、阅读状态等）
- 保留 WordPress 做前端展示，用户能在页面上搜索/筛选书库
- AI Agent 能直接查询，走 REST API 或 SDK，零中间层
- 开源自托管，数据归属自己
- 尽可能轻量（机器资源有限）
这个需求本质上是：数据库层、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 方案）
- Docker 起 Directus（官方 compose 文件，改个端口和密码）
- Wordpress 导出书籍 CSV，直接导入底层 PostgreSQL
- Directus 自动识别出 Collections 和 REST API
- WordPress 装 WP Data Access 插件，直连同一份 PG 数据库，用 Shortcode 做前端搜索/筛选/列表展示
- AI Agent 通过
curl $DIRECTUS_URL/items/books?filter查询
整个链路：一份 PG 数据 → Directus API（Agent）+ WP Data Access（WordPress），零冗余，零同步成本。