加载失败
pgrx 是一个用 Rust 开发 PostgreSQL 扩展的框架，适合把自定义逻辑直接编进数据库进程里。评论之所以反复提到它，是因为 PostgreSQL extension 本质上会加载本地机器码，既能带来高性能，也会带来安全和运维风险。托管版 PostgreSQL（例如 AWS RDS）通常只允许安装审核过的扩展，而 Supabase 这类服务会提供一组 curated extensions（例如 pg_cron、pgvector、unaccent、PostGIS）作为折中方案。讨论里还提到 PostgresML 曾基于 pgrx 构建，但该项目后来关闭；相对地，pgrx 本身仍在积极维护，并且已经被一些团队用于生产。
评论里有真实生产案例，说明 pgrx 不只是实验项目，而是已经能承载关键扩展。PlanetScale 的内部扩展都基于它构建，并且在一年的生产使用里没有遇到 memory unsafety 或 race conditions。另有开发者分享自己用 pgrx 写扩展体验很好，虽然为了更稳妥地控制复杂度，减少了一些“魔法”式能力，但整体支持依然很强。
有人起初以为这个项目已经停更，但很快被纠正：最近两周就有新 release，说明它仍在积极维护。评论还反复提到维护者非常友善、专业，遇到问题时在 Discord 里也很愿意帮忙。这个分支的重点不是功能本身，而是项目是否还在持续演进、以及社区支持是否可靠。
有评论把 pgrx 形容成一个已经“长出公司”的底层工具，很多 Postgres 扩展都建立在它之上。PostgresML 曾经基于它做产品，但后来公司关闭、域名也失效，这让部分人一度误以为相关生态已经不行了。随后又有人澄清 pgrx 本身仍在前进，说明真正持续活跃的是基础框架，而不是某个具体应用。
讨论的另一个核心问题，是很多托管 Postgres 平台并不允许随意装自定义扩展，AWS RDS 是最典型的例子。评论解释说，这是因为扩展会把本地机器码加载进数据库进程，在共享环境里会碰到安全和运维边界，所以云厂商通常只放行经过审核、不会触及受管组件的 curated extensions。Supabase 被拿来作为折中方案：它提供 pg_cron、pgvector、unaccent、PostGIS 等常用扩展，能覆盖不少实际需求，但仍然不能替代完全自定义扩展。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
pgrx: 一个用 Rust 编写 PostgreSQL extension 的框架/工具链，帮助把扩展代码编进数据库进程里。
AWS RDS: AWS 的托管 PostgreSQL 服务，通常只允许安装审核过的扩展，不支持任意自定义扩展。
GIN index: PostgreSQL 的 Generalized Inverted Index，常用于全文检索、标签匹配和模糊搜索。
PostgreSQL extension: 直接在 PostgreSQL 进程内加载的扩展模块，能增强数据库能力，但也带来安全和运维限制。