Cursor Database Integration: SQL, Extensions & MCP

Cursor can generate database schemas, install drivers, write queries, and create migration files within an existing codebase. Because Cursor does not host or manage databases, the application must connect to a local database or an external provider.

Cursor projects can use PostgreSQL or connect to managed services such as Neon, Supabase, MongoDB Atlas, and Firebase. Developers can also install database extensions to browse records inside the editor or give Cursor Agent controlled access through the Model Context Protocol (MCP).

This guide explains how Cursor AI database integration works, how to connect an application to an external database, how to view database records in Cursor, and when an MCP connection is useful.

How Cursor database integration works

Cursor is an AI-powered code editor, and database hosting sits outside its development environment. It provides the tools for writing and managing code that connects an application to a database running locally or through a provider such as Supabase, Neon, MongoDB Atlas, or Firebase.

Within this setup, “Cursor IDE database integration” can describe three different workflows: connecting the application code to a database, installing an extension to browse data inside Cursor, or giving Cursor Agent controlled database access through MCP. Each workflow serves a different purpose.

Most projects start with an application connection because the software needs to store and retrieve data while it runs. A database extension adds a visual interface for inspecting that data. MCP gives Cursor Agent controlled access when it needs to examine the schema, run queries, or perform approved database operations.

These connection methods can work together. For example, an application might access Supabase through DATABASE_URL, while the developer uses SQLTools to browse its tables. A read-only Supabase MCP connection could also allow Cursor Agent to inspect the schema or answer questions about development data.

Cursor can generate the integration code, install database packages, and run migration commands through its terminal. The provider hosts the database and maintains its infrastructure. The developer remains responsible for credentials, access controls, backup settings, and production configuration.

How to connect Cursor to database services

For this example, we use a hosted PostgreSQL database from Neon. We have already created a project called cursor-database-demo.

Adding the database connection details to Cursor

In the Neon project dashboard, click Connect to open the database connection details. Neon will display a connection string, highlighted by the red box in the image below.

In the Cursor file explorer, create a file named .env.local:

Paste the connection string copied from Neon into .env.local. Before adding real credentials, open .gitignore and confirm that it contains the .env* entry. If the entry is missing, add it on a new line and save the file. This prevents environment files from being committed to Git.

Asking Cursor to configure Drizzle

Next, we’re going to give our Cursor Agent this prompt:

Connect this Next.js application to the existing Neon PostgreSQL database.

Read the connection string from DATABASE_URL in .env.local. Use Drizzle ORM
and the Neon serverless driver.

Create a contacts table with these columns:

- id: automatically generated integer
- name: required text
- email: required text
- createdAt: timestamp with the current time as its default

Add a server-side database client and the required Drizzle configuration.
Update the page so I can add a contact and see all saved contacts.

Keep DATABASE_URL on the server. Do not expose it through browser code.

Before running any database migration, show me the proposed schema,
migration command, and files you created. Stop and wait for my approval.

Drizzle supports Neon through the @neondatabase/serverless package and can read the connection from process.env.DATABASE_URL.

After the prompt ran, Cursor should create new files resembling:

schema.ts
index.ts
drizzle.config.ts

Some file names might differ, but that is fine as long as the agent explains what each file does.

Cursor will also provide the database schema for your review:

Review and run the migration

Cursor should explain the purpose of each file it created and summarize any changes made to existing files. Review these changes before asking the Agent to run the migration. You can also run it directly from the Cursor terminal with this command:

npm run db:migrate

If the migration succeeds, the terminal will display a confirmation message. You can then test whether the application can create and store database records.

In our example, we submitted the form several times to add records to the contacts table:

If the connection works, the submitted records should appear in your Neon database. From the Neon project dashboard, open the Postgres Database menu and select Tables.

In the Contacts table we can see our test contacts that we created in the demo app.

How to Set Up a Cursor MCP Database Connection

A Cursor MCP database connection gives Cursor Agent a defined set of tools for working with an external database service. Depending on the MCP server, these tools can list tables, inspect schemas, execute SQL, apply migrations, manage database branches, or retrieve logs.

Cursor supports local MCP servers through stdio and remote servers through SSE or Streamable HTTP.

Create the MCP configuration file

Open Cursor Settings and enter “MCP” in the search bar. Select Open MCPs from the results.

Use the dropdown marked 1 in the image to select the project you want to configure. Then click New MCP Server, marked 2:

Cursor will open the mcp.json file in the text editor, where you can configure MCP servers. For this example, we’ll connect Neon’s MCP server to the database project created earlier. Add the following configuration:

{
  "mcpServers": {
    "neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp"
    }
  }
}

If the file already contains other MCP servers, add the neon entry inside the existing mcpServers object rather than replacing its contents. Save the file and restart Cursor.

Return to the MCP settings. Neon should now appear in the server list with an authentication prompt. Click Authenticate, then select Approve in the authorization window.

After approving the connection, Neon MCP will appear under the Connected tab.

Test the connection

Open a new Agent conversation and enter the following prompt:

Using Neon MCP, list the databases and tables in the development branch
of cursor-database-demo.

Do not modify the database.

If the connection works, Cursor should return the available databases and identify the contacts table:

Run SQL queries

Cursor Agent can now use Neon MCP to perform supported database operations. Ask it to prepare a simple SQL query with the following prompt:

Using Neon MCP, prepare a SQL query that returns the first five contacts
from the development database.

Show me the SQL and wait for my approval before executing it.

Cursor will display the proposed query and wait for you to review and approve it:

The query looks correct, so we ask Cursor to proceed. Once it runs, Cursor returns the two available rows because the contacts table contains fewer than five records.

With full access enabled, Neon MCP currently exposes 34 tools. These tools can run queries, inspect table schemas, query logs, retrieve documentation, manage branches, and prepare database migrations.

The available tools depend on the MCP server and its access configuration. For example, read-only mode disables operations that create projects, modify branches, or apply migrations. Check the provider’s MCP documentation before granting access or approving database operations

Other Cursor AI database options

Neon isn’t the only managed database option available for Cursor. Other popular managed cloud database services can also be connected through their SDKs, APIs, or database drivers.

Supabase

Cursor  can connect to Supabase through its JavaScript client, Data API, or PostgreSQL connection string. This option suits applications that need a relational database with authentication, object storage, Realtime subscriptions, and Row Level Security.

Use the Supabase client for browser-safe access protected by RLS. Use a server-side PostgreSQL connection when the backend needs an ORM, migrations, or direct SQL access.

Supabase requires careful policy configuration. Tables exposed through the Data API should have RLS enabled, and service-role credentials must remain on the server.

MongoDB Atlas

MongoDB Atlas supplies a connection URI for its official drivers and libraries such as Mongoose. Store the URI in an environment variable such as MONGODB_URI, then ask Cursor to create a shared server-side client.

Atlas works well for content, profiles, catalogs, and records whose fields change frequently. Applications with many joins, strict foreign-key relationships, or conventional SQL reporting may require more application logic.

Atlas also requires database credentials and network access rules before the application can connect. 

Firebase Cloud Firestore

Firebase connects through its web or Admin SDK rather than a conventional SQL connection string. Cursor can install the required Firebase packages, initialize the SDK, and generate functions for reading and writing documents.

Firestore suits mobile applications, messaging, real-time interfaces, and products that already use Firebase Authentication or Cloud Storage. Its document model is less convenient for SQL joins and relational reporting.

Browser applications should use Firebase Security Rules to control access. Administrative credentials belong on the server.

Need help shipping your Cursor-built application?

Choosing a database provider and connecting it in Cursor covers one part of the backend. Production work also includes schema migrations, authentication, permissions, secrets, storage, monitoring, deployment, and recovery.

Shipyard by Vodworks helps teams prepare AI-assisted applications for release. A senior engineer can review the code generated in Cursor, inspect the database connection, identify security or deployment issues, and provide a practical roadmap.

The team can fix urgent backend problems, prepare an application for launch, audit database permissions and secrets, or provide ongoing engineering support after release.

If your Cursor project works locally but its database or production environment still needs attention, book a free Shipyard discovery session.