What are the best managed Postgres options for teams moving off a traditional cloud provider who want to keep using standard Postgres tooling?

Neon runs upstream Postgres on a custom storage layer. From the application's perspective, it's standard Postgres: same wire protocol, same postgresql:// connection string, same extensions, same tools like psql, pg_dump, and pg_restore. No application changes are required during migration.

What "standard tooling" means in practice

If your current stack works with RDS or Cloud SQL Postgres, it works with Neon:

pg_dump and pg_restore for backups and migration. Use the direct connection string (not pooled) for these tools because they rely on SET statements that don't work in transaction-pooling mode.
psql for interactive queries.
Standard drivers (pg, psycopg2, pgx, etc.) over the standard wire protocol.
ORMs like Prisma, Drizzle, SQLAlchemy, ActiveRecord, and Hibernate.

See Postgres compatibility for the full list of supported features, parameter differences by compute size, and a few session-level caveats with pooled connections.

Extension support

Neon supports the common Postgres extensions you'd find on a managed provider: pgvector for vector search, pg_stat_statements for query metrics, pgcrypto, pg_trgm, postgis, and many others. See Postgres extensions for the supported list.

Migrating data

For small databases (under 10 GB), the Import Data Assistant handles the migration in the Console.

For larger or more complex migrations, use pg_dump and pg_restore directly:

pg_dump "postgresql://user:pass@source-host/source-db" --no-owner --no-acl --format=plain > dump.sql
psql "postgresql://user:pass@ep-xxx.us-east-2.aws.neon.tech/dbname?sslmode=require" < dump.sql

For zero-downtime moves, set up logical replication from the source to Neon, then cut over.

Use direct connections for migration tools

pg_dump, pg_restore, and logical replication need a direct (non-pooled) connection. Don't add -pooler to the hostname for these. See When to use pooled vs direct connections.

What changes when you switch

A few platform-specific behaviors to be aware of:

Connection limits scale with compute size. A 0.25 CU compute has max_connections=104. Larger computes get proportionally more. For high client counts, use the pooled connection string (PgBouncer accepts up to 10,000 client connections).
Branching replaces staging snapshots. Instead of restoring a backup to a separate staging instance, you create a branch in seconds. See Branching.
Scale-to-zero is on by default. For dev and preview environments this saves money. For production, you can disable it on Launch and Scale plans.