Supabase MCP：让 AI 直接查数据库，但别给它写权限

适合谁

使用 Supabase 开发应用、需要频繁调试数据库查询的开发者
希望用自然语言描述数据分析需求、让 AI 生成 SQL 并直接执行的人
需要快速了解数据库表结构、关系、数据分布的人
有数据库基础、能判断 AI 生成的 SQL 是否正确的开发者

不适合谁

数据库基础薄弱、看不懂 SELECT 和 JOIN 的新手
打算让 AI 直接修改生产数据的任何人（先用只读测试环境）
处理含用户隐私数据的数据库时（GDPR/隐私合规需要特别注意）
没有数据库备份机制的情况下开启写权限

3 分钟上手

安装

npx clawhub@latest install supabase

配置（从只读开始）

使用 Supabase 的只读 Role 配置连接：

# Supabase 控制台 → Database → Roles → 创建只读 role
# 或直接使用 anon key（已有 RLS 保护）
SUPABASE_MCP_URL=your-project-url
SUPABASE_MCP_KEY=your-anon-key  # 不要用 service_role

第一次正确使用

"查看数据库有哪些表" — 确认能看到表结构
"查询 users 表的前 10 条记录" — 确认数据读取正常
"skills 表里 download_count 最高的 5 个技能是什么" — 测试自然语言转 SQL

典型使用场景

场景 1：SQL 调试加速

你写了一个复杂查询，某个 JOIN 结果对不上。把表结构和查询发给 AI，让它分析问题所在，在数据库里验证修正后的查询——比自己反复试快得多。

场景 2：数据快速分析

"过去 7 天新增多少用户？哪些技能分类的安装量增长最快？" — 不用自己写 SQL，AI 理解你的问题然后直接查询，给出带数字的答案。

场景 3：表结构评审

"查看当前数据库结构，告诉我哪些表缺少索引，哪些关联关系可能有性能问题" — AI 分析 schema 并给出优化建议。

常见翻车点

用 service_role 配置：service_role 绕过所有 RLS，AI 就能看到/修改所有数据——这是最常见的配置错误
把生成的 DELETE/UPDATE 直接用于生产：AI 写的修改 SQL 不一定有 WHERE 条件的范围考虑
表名推断错误：AI 可能猜错你的表名命名约定，查了一个空表或完全不相关的表
把 AI 的数据分析当最终报告：数字正确不代表分析结论正确，业务含义需要你来解读

风险提示

权限风险

数据库读取：即使是只读，你的数据库内容会发送给 AI 处理——注意数据合规性
写权限开放后：AI 可执行任意 SQL，包括 DROP TABLE（虽然 Supabase 有保护层）

使用风险

查询性能影响：AI 生成的复杂查询可能在生产数据库上造成高负载
用户数据隐私：如果数据库含用户个人信息，让 AI 处理时需要符合隐私法规

建议

永远只用 anon key 或专用只读 role，不要用 service_role
AI 生成的写操作 SQL 在开发环境验证后再在生产环境执行
开启 Supabase 的审计日志，记录所有数据操作

适合谁