# Moltbook 数据库性能雪崩：RLS 策略下的高并发陷阱
## 现象：RLS 开启后数据库反而宕机
2026 年 2 月，Moltbook 上线 120 小时即全面瘫痪。安全机构 Wiz 的报告只是点燃了最后一根引线——真正的性能灾难，早在高并发 Agent 涌入时就已经埋下。
事故前的监控数据显示：
– 数据库 CPU 从 30% 飙升至 100%，持续 40 分钟无法回落
– API 响应 P99 Latency 从 120ms 恶化至 4.5s
– Supabase 连接池耗尽，新请求直接拒绝
表面看是流量过大，但核心问题指向一个看似正确的决策：开启 PostgreSQL RLS（Row Level Security）后，查询性能反而雪崩。
## 背景：什么是 RLS，为什么 Moltbook 选择开启它
RLS（Row Level Security，行级安全策略）是 PostgreSQL 9.5 引入的核心安全特性。它允许数据库在 SQL 执行层而非应用层强制执行访问控制，理论上可以做到：
| 特性 | 传统 App 层级控权 | RLS 层级控权 |
|——|——————|————–|
| 数据隔离 | 依赖应用代码过滤 | 数据库内核强制执行 |
| 越权风险 | 应用漏洞可导致数据泄露 | SQL 层面无法绕过 |
| 管理成本 | 每应用需单独实现 | 策略统一管理 |
Moltbook 作为一个 AI Agent 平台，涉及大量用户的私密对话、Agent 配置、个人数据。选择开启 RLS 本是合理的安全决策。然而，这个决策在超大规模并发场景下暴露出了设计时未充分考虑的性能隐患。
## 深层原因：RLS 策略评估的高并发陷阱
### 1. RLS 策略计算成本被严重低估
RLS 的工作原理是：每一条 SQL 在执行前，都需要经过所有已启用的 Policy 评估。Moltbook 的表结构涉及 `agents`、`conversations`、`messages` 三层嵌套，且 Agent 数量被虚假宣传至 150 万量级。
当 10 万个 Agent 同时通过脚本并发写入时，PostgreSQL 的 RLS Policy Evaluation 产生了笛卡尔积级别的计算压力：
“`sql
— 实际执行时，数据库内部等价于：
SELECT * FROM agents WHERE
owner_id = auth.uid() — Policy 1: 所有权检查
AND agent_status IN (SELECT status FROM agent_status_policies WHERE …) — Policy 2: 状态过滤
AND EXISTS (SELECT 1 FROM users WHERE users.id = agents.owner_id AND users.banned = false); — Policy 3: 用户状态联查
“`
Moltbook 的 schema 设计中，`agents` 表有 7 条 RLS 策略，且其中 3 条涉及跨表 JOIN。在 10k+ 并发写入场景下，每条 SQL 的策略评估耗时从 0.5ms 膨胀至 200ms，呈 400 倍恶化。
相关阅读：国行Thinkpad笔记本_深圳报价