Introduction

The PostgreSQL error “database does not exist” on AWS usually means your connection is targeting the wrong database name, wrong endpoint, or wrong environment. With RDS/Aurora, developers often connect successfully to the server but fail at database selection because default DB names differ from expectations.

A fast diagnosis checks endpoint, database name, user permissions, and quoting/case sensitivity.

Core Sections

1. Verify connection parameters

Check exact values:

• host endpoint (RDS instance or cluster)
• port
• username
• database name (dbname)

psql "host=mydb.xxxxxx.us-east-1.rds.amazonaws.com port=5432 user=app_user dbname=app_db sslmode=require"

2. List existing databases

Connect to known DB (often postgres) and list:

psql "host=... dbname=postgres user=app_user sslmode=require"
\l

If target DB is missing, create it or fix your app config.

3. Validate case and quoting

Unquoted PostgreSQL identifiers are folded to lowercase. If database was created with quoted mixed case, name must match exactly with quotes.

CREATE DATABASE "AppDB";
-- later requires dbname=AppDB with proper quoting semantics

Prefer lowercase names to avoid this class of issue.

4. Check user privileges and ownership

Even if DB exists, user may lack connect rights.

GRANT CONNECT ON DATABASE app_db TO app_user;

5. Environment mismatch and secret drift

In AWS, staging/prod endpoints and secrets are easy to mix. Confirm application secret store points to the same environment as endpoint.

Common Pitfalls

• Using default postgres locally but expecting same DB name in AWS app config.
• Pointing to wrong RDS/Aurora endpoint for selected environment.
• Ignoring PostgreSQL identifier case rules for quoted database names.
• Assuming DB exists because server is reachable.
• Rotating credentials/secrets without updating database name configuration.

Summary

“DB does not exist” in AWS Postgres is usually a configuration mismatch, not a network issue. Verify endpoint and dbname, list actual databases, and confirm privileges and naming conventions. Keep environment-specific settings explicit and consistent across secrets and deployment configs. With a short checklist, this error is usually resolved quickly.

A practical way to keep this guidance useful in real projects is to convert it into an executable runbook rather than leaving it as one-time reading. A strong runbook lists exact prerequisites, expected versions, environment assumptions, and a short sequence of checks that confirm healthy behavior. It also records the first one or two failure signatures engineers are most likely to see and maps each signature to the next diagnostic step. This structure reduces ambiguity when incidents happen under time pressure and helps new contributors act with the same consistency as experienced maintainers.

It also helps to keep one minimal reproducible fixture in version control for this exact scenario. The fixture can be a tiny script, API call, YAML manifest, query, or test harness that demonstrates both expected success and a known failure mode. When dependencies, frameworks, or infrastructure versions change, that fixture becomes an early warning system for regressions. Instead of discovering breakage deep in production workflows, teams can run a focused check in minutes and isolate whether the problem is environmental drift, configuration mismatch, or logic change.

For long-term reliability, add one lightweight automated guardrail to CI that targets the most fragile point in the workflow. Good candidates include schema validation, deterministic unit tests, protocol compatibility checks, API contract tests, and startup smoke tests. Keep the guardrail narrow and fast so it runs on every change and produces actionable output when it fails. If the same issue class appears repeatedly, promote the manual troubleshooting step into automation. Over time, this shifts effort from reactive debugging to preventive quality control, and ensures the article stays aligned with how teams actually build, test, and operate software.