| FMRS | 50 / 100 · D | 74 / 100 · B | 74 / 100 · B |
|---|
| Reliability | 8 / 20 | 13 / 20 | 13 / 20 |
|---|
| Security and permissions | 12 / 20 | 13 / 20 | 13 / 20 |
|---|
| Maintenance | 5 / 20 | 17 / 20 | 16 / 20 |
|---|
| Documentation | 14 / 20 | 16 / 20 | 15 / 20 |
|---|
| Setup experience | 11 / 20 | 15 / 20 | 17 / 20 |
|---|
| Best for | - Supabase developers using Cursor, Windsurf, Cline, or Claude Desktop.
- Teams that want SQL, project management, authentication administration, and logs in one interface.
- Development environments using local Supabase or Supabase.com-hosted projects.
| - Teams that want precise control over which database operations an AI can perform, rather than open arbitrary SQL execution
- Scenarios needing a unified MCP setup across multiple database engines
| - Scenarios wanting the smallest possible tool count and lowest context-window overhead for database access
- Cases needing to grant non-technical teammates safe, read-only database access
|
|---|
| Not for | - Users who need self-hosted Supabase support.
- Users who need custom connection strings or Session Pooling.
- Production teams that require ongoing maintenance, official support, or the latest features.
- Local-only Supabase users who need Management API or Auth Admin features.
| - Lightweight cases that just want to run a few ad-hoc SQL queries without maintaining a tools.yaml config (a simpler single-database MCP may be a better fit)
| - Scenarios needing database administration operations (creating indexes, altering schema) rather than just querying (DBHub is positioned as a query tool, not a DBA management tool)
|
|---|
| Required permissions | - Requires a database project reference and database password.
- All operations require a QUERY_API_KEY from thequery.dev.
- Management API operations require a Supabase personal access token.
- Auth Admin operations require a Supabase service role key.
- Database connections use transaction pooling; remote projects require the correct Supabase region.
| - Database credentials (username/password/connection string) are supplied via env vars or config
- A tool's actual permission is whatever SQL statement is defined in tools.yaml — designed for least privilege, but misconfiguration can still over-expose access
| - Requires a database connection string (DSN), which may contain sensitive credentials
- execute_sql can run arbitrary SQL (including writes) by default — must be constrained via read-only mode or the underlying database account's own permissions
|
|---|
| Risks and side effects | - Safe mode permits only low-risk read-only operations by default.
- Write operations require unsafe mode, and high-risk operations also require explicit confirmation.
- Extreme-risk operations, such as deleting a project, are blocked.
- Automatically generated migrations do not eliminate the risk of incorrect SQL or data loss when using high-privilege credentials.
- The service role key and database password are highly sensitive credentials.
- The project is no longer actively maintained, and the README points users to Supabase's official MCP server.
| - If tools.yaml defines SQL statements that allow unconstrained writes or deletes, the AI could accidentally modify data
- The prebuilt toolsets (--prebuilt) favor convenience and may expose broader query capability than a specific business actually needs — use a custom tools.yaml in production
| - Under default settings, if the connected database account has write access, execute_sql could let the assistant perform an unintended write or delete — pair with a read-only database account in production
- The DSN contains a plaintext password — pay attention to the access permissions on wherever the config is stored
|
|---|
| Supported clients | Cursor, Windsurf, Cline, Claude Desktop | Claude Code, Gemini CLI, Zed, Antigravity | Claude Desktop, Claude Code, VS Code, Cursor, Zed |
|---|
| Tools | 13 | 0 | 2 |
|---|