For Cursor projects

PostgreSQL for your Cursor projects, ready in seconds.

A copyable connection string. No AWS console, no setup, no yak shaving.

How we fit together

Cursor writes the code. Swyftstack runs the database.

Cursor sits in your editor; we sit at the other end of DATABASE_URL. Tell Cursor to read from process.env.DATABASE_URL and we'll have a managed Postgres ready in 47 seconds.

Cursor: your editor + AI pair

Cursor is the IDE. You prompt it, it writes the code, you ship. Cursor doesn't host anything - that's deliberate. You pick the runtime and the database.

Swyftstack: your data + your files

Managed PostgreSQL 16 on a single DATABASE_URL, plus app object storage on the same dashboard. SSL by default, daily backups, scoped credentials, and a single invoice for both.

PostgreSQL 16 Object storage
Setup

Three lines and you're shipping

DATABASE_URL="postgresql://user:pass@host:5432/dbname?sslmode=require"
What Cursor users typically build

Common Cursor + Swyftstack projects

SaaS prototypes

Next.js + PostgreSQL + S3 storage, fully working before you commit to a stack.

Internal tools

Quick admin dashboards backed by a real database.

Side projects

The ones that might be a business one day - they deserve a real backend.

Working with the agent

Getting database code out of Cursor you can trust

01

Keep the schema file open and committed

Cursor writes far better queries when it can see your table shapes. Keep prisma/schema.prisma or your Drizzle schema in the repo and open in a tab. With the real schema in context, it stops inventing column names and writes migrations that actually apply.

02

Pin conventions in a rules file

Add a .cursor/rules entry: database is managed PostgreSQL via process.env.DATABASE_URL with sslmode=require, use Prisma, never hard-code credentials. The agent then stops swapping in SQLite, changing the provider, or scattering connection strings through the code.

03

Make parameterised queries a standing rule

Put it in your rules: always use parameterised queries, never interpolate user values into a query string. Injection bugs are easy for an agent to introduce and trivial to prevent. ORMs parameterise by default; for raw SQL, confirm values are passed as bound parameters.

04

Read the SQL before you run it, and run migrations yourself

An agent will happily write a query that scans a million rows. Skim generated SQL: does it filter on an indexed column, fetch only what it needs, avoid an N+1? Run migrations in the terminal so you read the diff first, and back up before any destructive change.

Frequently asked

Can I open Prisma Studio against my Swyftstack database?

Yes. We're a standard Postgres host, so `npx prisma studio` connects over your DATABASE_URL with no extra config. The same is true for Drizzle Studio, TablePlus, DBeaver, and psql.

What about staging vs production?

Spin up a second database. The Launch plan covers up to 3 databases, so you get separate dev / staging / prod environments without separate accounts or separate bills. Each has its own connection string.

Can I run psql and migrations in Cursor's terminal?

Yes. Cursor's integrated terminal is a normal shell - `psql $DATABASE_URL`, `prisma migrate dev`, and `drizzle-kit push` all work. We recommend running migrations yourself in the terminal rather than letting the agent run them, so you stay in control of schema changes.

Should I let Cursor's agent connect directly to my database?

Point Cursor at a dev database, never production. Cursor writes code against your schema file; it doesn't need live prod credentials. Keep your prod DATABASE_URL in your deploy platform's env vars, not in the repo Cursor can read.

Cursor keeps regenerating my Prisma client incorrectly - how do I stop that?

Add a project rule (`.cursor/rules` or `.cursorrules`) that says: "Database is PostgreSQL via DATABASE_URL. Use the existing prisma/schema.prisma. Do not change the provider or datasource." Pinning conventions in a rules file stops the agent from drifting.

Is this real PostgreSQL or a fork?

Real PostgreSQL 16, straight from postgresql.org. We don't fork or modify the engine. pg_dump, psql, and any standard client work normally.

Where is my data stored?

US or EU - you pick at signup. Encrypted in transit and at rest. Backups are encrypted with separate keys.

Can I move off Swyftstack later?

Yes. PostgreSQL is standard Postgres, and bucket objects can be exported. Take a pg_dump or export your files anytime - we'll even help.

What happens if I outgrow the Launch plan?

Click upgrade. Same database, same connection string, more capacity. No downtime, no migration.

Do I need to manage SSL myself?

No. SSL is on by default, certificates are managed and auto-renewed. Standard rejectUnauthorized: true works out of the box.

Deploy a database for your Cursor project.

Try free for 14 days, then $19/mo. Includes 3 databases for dev / staging / prod. No card required.