How to Connect Cursor to PostgreSQL with MCP [Step-by-Step]

The problem

You open Cursor, ask it to write a query, and it invents table names. Or guesses column types. Or hallucinates a JOIN that doesn't exist in your schema.

This happens because Cursor doesn't know your database. It's working blind, generating SQL from vibes and training data.

MCP (Model Context Protocol) fixes this. It gives Cursor a live connection to your PostgreSQL schema: tables, columns, types, foreign keys, indexes. When Cursor knows your actual data model, it writes correct SQL on the first try.

This guide shows how to connect Cursor to PostgreSQL through DataMCP, an MCP gateway that handles auth, permissions, and logging so you don't ship your raw connection string in a JSON file.

What you'll get

Once connected, Cursor gets access to six MCP tools:

• query executes SQL against your database. SELECT by default, INSERT/UPDATE/DELETE if you allow it. 100-row limit, 30-second timeout.
• get_schema returns your full schema: every table, column, type, foreign key, and index. Each table and column comes with an AI-generated description so Cursor understands what trx_ref_id actually means.
• get_table_details dives deep into a single table: constraints, relationships, column defaults.
• get_permissions tells Cursor what it's allowed to do before it tries. If a tool is restricted to read-only, Cursor sees that upfront and won't attempt an INSERT.
• get_schema_changes shows what changed in your schema since the last sync. Useful when Cursor's context feels stale after a migration.
• resync_schema forces a fresh schema pull from your live database.

Cursor calls these tools automatically when it needs context. You ask "write a query to find users who signed up this week" and Cursor calls get_schema, sees your users table has a created_at timestamp column, and writes the correct WHERE clause.

Setup (takes about 2 minutes)

1. Register your PostgreSQL connection

Go to dashboard.datamcp.app and sign up. Click "Add Connection", paste your PostgreSQL connection string, and hit Test.

DataMCP connects to your database, extracts the schema, and generates AI descriptions for every table and column. Your connection string is encrypted with AES-256-GCM before storage. DataMCP never stores plaintext credentials.

Works with PostgreSQL 12+ from any provider: Supabase, Neon, AWS RDS, Google Cloud SQL, Azure, DigitalOcean, Heroku, or self-hosted.

2. Create an MCP link

An MCP link is a scoped access point. Each link has its own permission level:

• Read-only grants SELECT and schema viewing. This is what you want for most AI coding work.
• Read-write adds INSERT, UPDATE, DELETE. Useful if you want Cursor to help with seed data or test fixtures.
• Full access includes DDL (CREATE TABLE, ALTER, DROP). Use with caution.
• Custom lets you pick permissions per table. Allow SELECT on products and orders, block access to billing_events entirely.

Every query Cursor runs through the MCP link is validated against these permissions before execution. If Cursor tries to DELETE from a table it doesn't have write access to, the query gets blocked and Cursor receives an explanation of why.

3. Add the config to Cursor

DataMCP gives you a URL and an API key. Drop them into ~/.cursor/mcp.json:

{
  "mcpServers": {
    "my-project-db": {
      "url": "https://mcp.datamcp.app/api/mcp/YOUR_CONNECTION_ID",
      "headers": {
        "Authorization": "Bearer sk_live_YOUR_API_KEY"
      }
    }
  }
}

Restart Cursor. That's it. You should see your MCP server listed in Cursor's MCP panel. From this point, every conversation has access to your PostgreSQL schema.

On Windows the config path is %USERPROFILE%\.cursor\mcp.json.

4. Try it

Open a new Cursor chat and ask something that requires your schema:

"Show me the 10 most recent orders with customer email and total amount"

Cursor will call get_schema, find your orders and customers tables, see the foreign key between them, and write the correct JOIN with proper column names. No hallucinated tables, no guessed column types.

What happens under the hood

When Cursor sends a request through MCP, here's the actual flow:

1. Cursor calls get_schema via the MCP URL
2. DataMCP validates the API key and resolves the MCP link's permission scope
3. The cached schema (with AI descriptions) is returned to Cursor
4. Cursor generates SQL based on the real schema
5. Cursor calls query with the SQL statement
6. DataMCP parses the SQL and checks it against the permission scope: is SELECT allowed? Does the link have access to these specific tables?
7. If allowed, the query runs against your PostgreSQL with a 30s timeout and 100-row limit
8. Results go back to Cursor, along with execution time and row count
9. The entire interaction is logged: query text, status, execution time, which MCP link was used

Every step is logged in the Activity tab on your dashboard. You can see exactly what queries your AI tools ran, when, and whether anything was blocked.

Permissions in practice

Say your team has a staging database with sensitive tables. You want Cursor to help with feature development but not touch users.email or anything in the billing schema.

With DataMCP's Custom preset you can:

• Allow SELECT on public.products, public.orders, public.categories
• Block all access to billing.*
• Block the users table entirely, or allow SELECT but only on specific columns through PostgreSQL's native column-level grants

Each developer on your team can have their own MCP link with different permission scopes. A junior dev gets read-only on the tables they're working on. A senior gets read-write on everything except production billing data. All from the same PostgreSQL connection.

Team setup

DataMCP is built around organizations. Everyone on your team joins the same org, and all connections and MCP links belong to that org.

Roles control who can do what:

• Owner manages billing, members, and all connections
• Admin manages connections and can create MCP links with any permission level
• Member uses existing connections and creates MCP links within their assigned scope

When a new developer joins the team, an admin invites them by email, assigns a role, and they instantly get access to the MCP links they need. When someone leaves, revoke their access in one click. No shared credentials to rotate, no config files to track down.

Works with other tools too

The same MCP connection you set up for Cursor also works with:

• Claude Desktop via mcp-remote (wraps the HTTP transport)
• VS Code natively in ~/.vscode/mcp.json, same config format as Cursor
• Windsurf, Kiro, Zed all support MCP natively
• Claude Code via claude mcp add --transport streamable-http

Each tool gets its own MCP link with its own permissions. One connection, multiple tools, different access levels.

Pricing

The free tier includes 1 PostgreSQL connection, 1 MCP link, and 2 team members with 7-day log retention. Enough to try it on a personal project.

Pro ($19/month) bumps that to 3 connections, 5 MCP links per connection, 5 team members, 30-day logs, and custom per-table permissions.

Enterprise ($49/month) scales to 15 connections, 50 MCP links, 25 members, and 365-day audit logs.

No contracts, no cancellation fees, downgrade to free anytime.

Get started

1. Sign up at dashboard.datamcp.app
2. Add your PostgreSQL connection
3. Create a read-only MCP link
4. Paste the config into ~/.cursor/mcp.json
5. Restart Cursor and ask it about your data

The whole thing takes less than 2 minutes. Once Cursor has your schema, you'll wonder how you ever coded without it.