Getting ready for production

Use a paid plan for production workloads

Neon's paid plans are fully usage-based, which means your database is never subject to fixed limits that can stop your application as traffic grows. You pay for the compute and storage you use each month, without minimums.

The Free plan is designed to support experimentation and prototyping and includes compute hour limits. It should be avoided for production workloads where uninterrupted availability matters.

If you need technical support beyond billing, the Scale plan includes priority support with access to Neon's support team.

Keep reading: Neon plans

Choose a region close to your application

Network latency is one of the most common contributors to database response time: even a well-tuned database will feel slow if it's geographically far from your application servers. When creating a Neon project, choose the region that is closest to where your application runs.

Keep reading: Neon regions

Keep your production branch as the default root branch

Your production database should run on a root branch that is set as the project's default branch. Neon projects are configured this way by default. Using a root branch enables snapshots, provides simpler billing (based on actual data size rather than accumulated changes), and prevents accidental deletion.

Keep reading: Manage branches

Protect your production branch

Neon makes it easy to branch, reset, and restore databases. In production, that power should be paired with explicit safeguards. Branch protection helps ensure that powerful features like restore, reset, and snapshot operations are used deliberately when applied to production data. This is especially important in teams or automated environments.

Keep reading: Protected branches

Enable autoscaling and set appropriate limits

Neon autoscaling automatically adjusts compute resources based on your workload, allowing your database to absorb traffic spikes without manual intervention. For production workloads:

• Minimum compute size: Set a minimum high enough so your working set (frequently accessed data) can be fully cached in memory. This is important because Neon's Local File Cache (LFC) allocation is tied to your compute size. When the compute scales down and the LFC shrinks, frequently accessed data may be evicted and need to be reloaded from storage, which impacts performance.

• Maximum compute size: Set a maximum that provides enough extra capacity for traffic spikes. The maximum also determines your available local disk space, which is used for things like temporary files, complex queries, pg_repack, and replication.

A safe minimum combined with a sufficiently high maximum will give you the best performance while avoiding unnecessary baseline cost.

Keep reading:

• How to size your compute
• Autoscaling configuration
• Monitor working set size
• How the autoscaling algorithm works

Decide whether scale-to-zero is acceptable

Scale-to-zero allows Neon to suspend compute after a period of inactivity. This is a highly effective way to save costs in development environments and workloads with intermittent usage. For production workloads, the decision depends on your latency requirements.

If occasional cold starts are acceptable for your application (e.g., for internal tools), leaving scale-to-zero enabled will be the most cost-effective choice.

Consider disabling scale-to-zero if:

• Your application requires consistently low latency
• Cold-start delays are unacceptable for user-facing requests
• You rely on long-lived sessions or in-memory state

Cache considerations: When a compute suspends, the cache is cleared. After the compute restarts, rebuilding the cache can take some time and may temporarily degrade query performance. If your workload requires suspension but you want to minimize this impact, consider using the pg_prewarm extension to reload critical data into the cache on startup.

Keep reading: Scale to zero configuration

Test connection retries using the Neon API

In a serverless architecture, brief connection interruptions can occur during scaling events or maintenance. Most database drivers and connection pools already implement retry logic for transient failures, but rather than assuming this works, you should test it.

Our recommended approach:

• Use the Neon API or Console to trigger a compute restart
• Observe how your application behaves during the restart
• Confirm that connections are re-established automatically without user-facing errors

curl --request POST \
     --url https://console.neon.tech/api/v2/projects/{project_id}/endpoints/{endpoint_id}/restart \
     --header 'accept: application/json' \
     --header 'authorization: Bearer $NEON_API_KEY'

Keep reading:

• Restart a compute
• Build connection timeout handling into your application
• Maintenance and updates overview

Set an appropriate restore window

Neon retains a history of changes for each project to support branching and instant restores. On paid plans, the default restore window is 1 day, which you can increase up to 30 days.

Increasing the restore window gives you more flexibility to recover from bugs discovered later or accidental data loss. However, longer restore windows retain more historical data, which contributes to storage usage. Choose a window that balances recovery needs with predictable storage costs.

Keep reading: Storage and billing for restores

Consider snapshot schedules

Snapshot schedules provide regular, durable restore points taken daily, weekly, or monthly. While point-in-time restore lets you roll back to any moment within the restore window, snapshots capture stable points in time that you can return to later — ensuring that recovery points exist even if they fall outside your chosen restore window.

Snapshot schedules are only available on root branches.

Keep reading: Snapshot schedules

Test your restore workflow

Don't wait for an incident to learn how restore works. Plan and test your recovery process in advance.

Neon supports multiple restore patterns:

• Instant branch restores, where the existing branch is restored to a previous state
• Restore from a snapshot into the same branch
• Restore from a snapshot into a new branch

Plan and test which restore method you will use for production incidents, how your application will switch connections if a new branch is created, and how you will validate restored data before resuming traffic.

Clean up your branches regularly

Neon's branching makes it easy to create preview, test, and temporary environments. Over time, unused branches can accumulate and contribute to unnecessary storage usage. To keep costs and complexity under control:

• Set expiration times for preview and test branches
• Add explicit delete steps to automated branching workflows
• Periodically review and remove branches that are no longer in use

Keep reading:

• Branch expiration
• Automate branching with GitHub Actions
• Plans and billing

Use pooled connections where they make sense

Connection pooling increases the number of concurrent clients your database can serve (up to 10,000) by reusing a smaller number of backend connections. This reduces connection overhead and improves performance in web and serverless applications.

However, pooled connections are not appropriate for all workloads. Avoid them for:

• Long-running database migrations
• Workloads that rely on session-level state
• Administrative tasks that require persistent connections (e.g., pg_dump)
• Logical replication (CDC tools like Fivetran, Airbyte)

Keep reading: Connection pooling

Restrict access to production data

Neon's IP Allow feature ensures that only trusted IP addresses can connect to your database, preventing unauthorized access and enhancing security. Combine an allowlist with protected branches for enhanced security.

Keep reading: IP Allow

Install pg_stat_statements

The pg_stat_statements extension provides query performance monitoring to track execution times and frequency. Since Neon doesn't log queries and has limited visibility into query performance, this extension helps you troubleshoot issues independently.

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

The statistics gathered by this extension require little overhead and let you quickly access metrics like:

• Most frequently executed queries
• Longest running queries
• Queries that return the most rows

You can also use the Monitoring Dashboard in the Neon Console to view live graphs for system and database metrics like CPU, RAM, and connections.

Keep reading:

• Query performance
• Monitoring

Integrate with your existing observability stack

If you already operate an observability platform, you can export Neon metrics and logs to monitor database behavior alongside the rest of your system. This helps you:

• Track connection counts and usage patterns
• Monitor compute and storage growth over time
• Correlate database behavior with application-level events

You can export to any OTLP-compatible platform, Datadog, or Grafana Cloud.

Keep reading:

• OpenTelemetry export guide
• Datadog export guide
• Grafana Cloud export guide