corpusctl vs Directus：一个内容平台对上一个数据库包装层

#Directus 留给你自己的那部分

Directus 停在 API 这一层。已发布的内容到底如何送达访客——缓存、失效、静态生成、CDN——都是你的项目。对于想要那种控制权的团队来说，这是正确的设计。

corpusctl 把它一并交付。点击发布会触发构建流水线：内容被校验、渲染，并写入对象存储中一个不可变、以哈希寻址的文件，随后刷新清单。访客的客户端在本地把 slug 解析到某个清单分片，并从nginx 边缘缓存中取回那个地址——可缓存三十天，因为同一个地址永远不会返回不同的内容。

重点就在其后果：

• 访客流量永远不会到达 API 或 PostgreSQL。
• 没有按次计费的表，因为根本没有按次调用。
• 读取性能不会随内容量增长而下降。清单是分片的，所以一个有一万条条目的 space 依然只下载一个小文件。

如果你在 Directus 上自己构建那一层，你大致就会构建出这个。问题在于你是否想要去做。

#多项目

Directus 在一个项目内部按集合（collection）组织；要运行多个相互隔离的客户项目，就意味着多个实例，或一套由你自己在访问规则中设计并维护的多租户方案。

在 corpusctl 中，多租户位于核心，紧挨着 auth 和模块注册表：一个面板、无限个 space，隔离由PostgreSQL 行级安全强制执行——在数据库中，位于那个存在被遗忘过滤条件的应用层之下。

这个理由很窄：应用层的隔离一直有效，直到那条漏掉过滤条件的查询出现——而那条查询终究会被写出来，由某个赶时间的人，在某个没人仔细审查的模块里写下。

#模块，以及关掉一个意味着什么

corpusctl 的每个功能都是一个模块——媒体、搜索、webhooks、SEO、GraphQL、导入、分析——而且每个都可以被移除而不弄坏构建。模块之间不得互相 import；服务注册表和事件总线是它们之间唯一的通道。pnpm check:isolation 在这条规则被打破时会让 CI 失败。

计划降级会把模块设为disabled，并且从不删除数据。

#Directus 胜出的地方

自带数据库。 那个招牌能力，而 corpusctl 并不尝试。corpusctl 拥有自己的 PostgreSQL 模式，带哈希分区和行级安全；你不能把它指向一个现有的数据库。

Flows。 产品内置的可视化自动化构建器。corpusctl 有 webhooks 和事件总线——更多代码，更少点击。

任意 SQL 引擎。 PostgreSQL、MySQL、SQL Server 等等。corpusctl 有意只支持 PostgreSQL：RLS 和哈希分区是我们所依赖的 Postgres 特性。

一个真正免费的免费档， 再加上面向小型组织的开放创新资助（Open Innovation Grant）。

成熟度。 大约 37,000 个 GitHub star，以及比 corpusctl 更长的发展历程。

#诚实的总结

如果你已经有一个数据库、需要把它包裹起来而不是替换掉，或者想要可视化的自动化流程，那就选 Directus。

如果你希望内容路径——构建、缓存、送达——到手就是成品，希望从一个面板管理多个项目，并且没有按席位计费项，那就选 corpusctl。

Directus 价格取自 directus.io/pricing，2026 年 8 月 17 日。价格会变——引用前请核实。

查看架构 → · 阅读文档 →