RealComposer
START FREE
Edge Runtime & DataOfficial Neon Postgres docs

Neon Postgres Safe & Unsafe Practices

Direct Answer

Neon connection strings contain credentials and are server-only. Use pooled connection URLs or the serverless driver from edge and serverless code, give each application a least-privilege role, and use branches to keep development off production data.

Credentials & Where They Belong

Server only
DATABASE_URL connection string

Includes role name and password.

Server only
Neon API key

Manages projects, branches, and roles.

Safe Practices

  • Use pooled connections from serverless runtimes

    The -pooler hostname or HTTP driver avoids exhausting connections under bursty traffic.

  • Create least-privilege roles per service

    Grant only the schema and table permissions each app needs.

  • Develop on branches

    Branches isolate schema changes and tests from production data.

Unsafe Practices

  • Exposing the connection string to clients

    Anyone with it can connect directly with that role permissions.

  • Using the owner role for application traffic

    A SQL injection then grants full control of the database.

The RealComposer Pattern

RealComposer stores pipeline configs and encrypted vault entries in Neon, connecting from Workers with server-only credentials and parameterized queries.

START BUILDING FREE

Frequently Asked Questions

Q:Should I use the pooled Neon URL from Workers?

Yes for most serverless traffic, or use the Neon serverless driver over HTTP for one-shot queries.

Related Concepts

Connection Pooling

Connection pooling is maintaining a set of open, reusable connections to a database or upstream service so requests can borrow an existing connection instead of opening a new one. It avoids repeated TCP and TLS handshakes and prevents exhausting server connection limits.

Principle of Least Privilege

The principle of least privilege states that every user, service, and credential should have only the minimum permissions required to perform its task. For APIs, this means using restricted keys, narrow OAuth scopes, and client tokens limited to specific endpoints.

Encryption at Rest

Encryption at rest is protecting stored data by encrypting it on disk or in a database, so it is unreadable without the decryption key. For secret vaults, each API key is encrypted with strong algorithms like AES-256-GCM and decrypted only at the moment it is needed.