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.

If you want the product architecture and permission model before the tutorial, review the hosted PostgreSQL MCP server page.

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

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://api.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 PostgreSQL query activity is logged with its status, execution metadata, connection, and MCP link

The Activity tab shows PostgreSQL query activity and denied operations. Schema-discovery calls are not presented as database queries, so use the query history to review executed SQL and enforcement outcomes rather than treating it as a transcript of every MCP message.

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 or client can use a separate MCP link with a different permission scope. One link can be read-only on selected tables while another permits approved writes, all from the same PostgreSQL connection and still bounded by the connected database role.

Team setup

datamcp organizes connections and MCP links inside organizations. Invite teammates to the organization, use separate MCP credentials where practical, and revoke an individual link or API key when access is no longer needed. This avoids putting the underlying PostgreSQL password into every developer's configuration.

Works with other tools too

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

• Claude Desktop through the Claude PostgreSQL setup guide
• ChatGPT through a separate OAuth-enabled link when the workspace meets the current ChatGPT MCP requirements
• VS Code through its MCP configuration, which uses a top-level servers object rather than Cursor's mcpServers
• Windsurf, Kiro, Zed all support MCP natively
• Claude Code via claude mcp add --transport 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) includes 3 connections, 5 MCP links, 5 team members, and 30-day logs.

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

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 Free plan supports one PostgreSQL connection and one MCP link, which is enough to verify schema access, a read-only query, and a denied write before deciding whether to expand the setup. Supabase users can first review the Supabase MCP server overview to choose between platform-wide and database-focused access.