Production Database Setup for Startups: PostgreSQL on AWS (What to Actually Do)

A local SQLite database or a free hobby-tier Postgres instance is the right call while you are building and validating. The moment real users start storing data you care about, you need a production database setup — one that survives server restarts, has automated backups, is not exposed to the public internet, and can be scaled without data loss.

The most reliable managed PostgreSQL option on AWS is Amazon RDS for PostgreSQL. You pay for a running instance whether you are using it or not, but you get automated daily backups, point-in-time recovery, automatic minor version patching, and Multi-AZ failover if you need it. A db.t4g.micro instance (2 vCPUs burstable, 1 GB RAM) costs around $13 to $16 per month with 20 GB of gp3 storage. That is enough for a startup with up to a few hundred thousand rows and modest query traffic. A db.t4g.small (2 GB RAM) at around $26 per month handles most early-traction apps comfortably.

The first critical configuration decision is network placement. Your RDS instance must go into a private subnet — a subnet with no direct route to the internet. Only your application server (the EC2 instance or container running your API) should be able to reach the database, via a security group rule that allows TCP 5432 from the application server's security group only. Never open port 5432 to 0.0.0.0/0. This is the most common misconfiguration that exposes production databases.

For connection management, most Node.js applications use a connection pool — pg-pool for raw Postgres, or the built-in pooler in an ORM like Prisma or Drizzle. Production apps should configure a pool of 5 to 20 connections depending on traffic. RDS connection limits are tied to instance memory: a db.t4g.micro supports around 40 connections max. If you exceed that, connections queue up or fail. If you are running multiple application servers (or serverless functions), consider PgBouncer as a connection pooler in front of RDS to multiplex connections.

Backups are non-negotiable. RDS automated backups are enabled by default and retain snapshots for 7 days (you can extend to 35 days). Before any significant database migration or data cleanup, take a manual snapshot from the RDS console or via the CLI — aws rds create-db-snapshot. Manual snapshots persist until you delete them. Point-in-time recovery lets you restore to any second within your retention window, which has saved teams from accidental mass-deletes more times than anyone likes to admit.

Schema migrations in production require care. Running CREATE TABLE IF NOT EXISTS or adding a column with ALTER TABLE ADD COLUMN IF NOT EXISTS is safe because it is backward compatible. Dropping a column or renaming a column is dangerous — if your old application code references the old name before you deploy the new code, requests fail. The pattern is: deploy code that works with both old and new schema, migrate the schema, then remove the old compatibility code in a follow-up deploy.

For connection strings, store the database URL as a secret in AWS Secrets Manager or SSM Parameter Store, not in your code or a .env file committed to git. Your application reads it at startup via the AWS SDK or CLI. Secrets Manager also supports automatic rotation for RDS passwords.

If you want a simpler alternative to RDS for early-stage projects, Supabase gives you a managed PostgreSQL instance with a REST API, authentication, and a dashboard — useful when you do not want to manage VPC networking. Neon is another option with a serverless PostgreSQL model that scales to zero when unused, reducing cost for intermittently active apps.

The bottom line: get your database into a private subnet behind a security group, turn on automated backups, use a connection pool, and store your credentials in a secret manager. These four steps take a few hours to configure but protect you from the most common production database failures.