PostgreSQL

Stackpad provides managed PostgreSQL 16 databases as project services. Each database runs in its own container on the project’s private network with automatic backups and encrypted credentials.

Creating a PostgreSQL service

1. Open your project in the dashboard
2. Click Add Service
3. Search for or select PostgreSQL
4. Click Add

Stackpad provisions a PostgreSQL 16 instance with:

• Auto-generated credentials — username, password, and database name
• AES-256-GCM encrypted password
• Persistent storage — data survives container restarts
• Private network access — reachable at postgres:5432 from other services

Connecting from your application

Stackpad automatically injects DATABASE_URL into all sibling web services in the same project:

postgresql://stackpad_user:auto_generated_pass@postgres:5432/stackpad_db

Use this in your application:

// Plain pg
import { Pool } from 'pg';
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// Drizzle ORM
import { drizzle } from 'drizzle-orm/node-postgres';
const db = drizzle(process.env.DATABASE_URL!);

// Prisma — in schema.prisma:
// datasource db {
//   provider = "postgresql"
//   url      = env("DATABASE_URL")
// }

The postgres hostname resolves via the project’s private DNS — no IP addresses or external connection strings needed.

Adding a database to an existing project

If you add PostgreSQL to a project that already has a running web service:

1. DATABASE_URL is created immediately in Stackpad’s database
2. But the running container doesn’t see it yet — it was started before the variable existed

Caution

You must redeploy your web service after adding a database. Click Redeploy on the web service to pick up the new DATABASE_URL.

Running migrations

Your application needs to handle database migrations. Common approaches:

• Prisma: Add prisma migrate deploy to your build command or start script
• Drizzle: Run drizzle-kit push as part of your deployment
• Raw SQL: Run migrations on application startup

Since DATABASE_URL is available at both build time and runtime, you can run migrations during the build or when the app starts.

Connecting from outside Stackpad

By default, PostgreSQL is only accessible from within the project’s private network. If you need to connect from your local machine (e.g. for debugging or running migrations manually):

1. Go to the PostgreSQL service detail page
2. Open the Settings tab
3. Enable Public access

Caution

Enabling public access exposes your database on a random TCP port (in the 40000–60000 range) on Stackpad’s control node. The connection string is shown in the dashboard after enabling.

Only enable this when you need it and consider disabling it when you’re done. The database is still protected by its password, but reducing exposure is always better.

After enabling, you can connect with any PostgreSQL client:

psql "postgresql://stackpad_user:pass@control-node-ip:4XXXX/stackpad_db"

Backups

PostgreSQL databases are automatically backed up using pg_dump:

Plan	Frequency	Retention
Starter	Daily	7 days
Pro	Every 6 hours	30 days
Business	Hourly	90 days

Backups are stored on European S3-compatible storage. See Backups for details on viewing and restoring.

Resource limits

Plan	Storage	RAM	CPU
Starter	256 MB	256 MB	0.25 cores
Pro	1 GB	512 MB	0.5 cores
Business	5 GB	1 GB	1 core

These limits apply per service. If you have PostgreSQL in both production and staging environments, each gets its own allocation.

Security

PostgreSQL services run with a hardened container security profile:

• SYS_NICE and IPC_LOCK capabilities for database performance
• no-new-privileges flag enabled
• PID limits to prevent fork bombs
• Isolated on the project’s Docker network — not accessible from other projects
• Credentials encrypted with AES-256-GCM at rest

What’s next?

• Connecting services — how private networking works
• Environment variables — how variable scoping and auto-injection work
• Backups — manage and restore database backups
• MariaDB — use MariaDB instead of PostgreSQL