Postgres compatibility

Neon is Postgres. However, as a managed Postgres service, there are some differences you should be aware of.

Postgres versions

Neon supports Postgres 14, 15, and 16. You can select the Postgres version you want to use when creating a Neon project. Postgres 16 is selected by default. For information about creating a Neon project, See Manage projects. Minor Postgres point releases are rolled out by Neon after extensive validation as part of regular platform maintenance.

Postgres extensions

Neon supports numerous Postgres extensions, and we regularly add support for more. For the extensions that Neon supports, see Postgres Extensions. To request support for additional extensions, please reach out to us on our Discord Server. Please keep in mind that privilege requirements, local file system access, and functionality that is incompatible with Neon features such as Autoscaling and Autosuspend may prevent Neon from being able to offer support for certain extensions.

Roles and permissions

Neon is a managed Postgres service, so you cannot access the host operating system, and you can't connect using the Postgres superuser account. In place of the Postgres superuser role, Neon provides a neon_superuser role.

Roles created in the Neon Console, CLI, or API, including the default role created with a Neon project, are granted membership in the neon_superuser role. For information about the privileges associated with this role, see The neon_superuser role.

Roles created in Neon with SQL syntax, from a command-line tool like psql or the Neon SQL Editor, have the same privileges as newly created roles in a standalone Postgres installation. These roles are not granted membership in the neon_superuser role. You must grant these roles the privileges you want them to have. For more information, see Manage roles with SQL.

Neon roles cannot install Postgres extensions other than those supported by Neon.

Postgres parameter settings

The following table shows parameter settings that are set explicitly for your Neon Postgres instance. These values may differ from standard Postgres defaults, and a few settings differ based on your Neon compute size.

Parameter settings that differ by compute size

Of the parameter settings listed above, the maintenance_work_mem, max_connections, and max_worker_processes differ by compute size, which is defined in Compute Units (CU). The following table shows values for each compute size.

Configuring Postgres parameters in a session context

Neon permits configuring parameters that have a user context, meaning that the parameter can be set by a connected user within a specific session using a SET command. These parameters are also referred to as "run-time parameters". You can identify Postgres parameters with a user context by running the following command:

SELECT name
FROM pg_settings
WHERE context = 'user';

For example, the maintenance_work_mem parameter supports a user context, which lets you set it for the current session with a SET command:

SET maintenance_work_mem='1 GB';

Postgres server logs

Currently, Postgres server logs can only be accessed Neon Support team. Should you require information from the Postgres server logs for troubleshooting purposes, please contact Neon Support.

Unlogged tables

Unlogged tables are maintained on Neon compute local storage. These tables do not survive compute restarts (including when a Neon compute instance is placed into an Idle state after a period of inactivity). This is unlike a standalone Postgres installation, where unlogged tables are only truncated in the event of abnormal process termination. Additionally, unlogged tables are limited by compute local storage size.

Memory

SQL queries and index builds can generate large volumes of data that may not fit in memory. In Neon, the size of your compute determines the amount of memory that is available. For information about compute size and available memory, see How to size your compute.

Temporary tables

Temporary tables, which are stored in compute local storage, are limited by compute local storage size.

Session context

The Neon cloud service automatically closes idle connections after a period of inactivity, as described in Compute lifecycle. When connections are closed, anything that exists within a session context is forgotten and must be recreated before being used again. For example, in-memory statistics, temporary tables, prepared statements, advisory locks, and notifications and listeners defined using NOTIFY/LISTEN commands only exist for the duration of the current session and are lost when the session ends.

Statistics collection

Statistics collected by the Postgres cumulative statistics system are not saved when a Neon compute (where Postgres runs) is suspended due to inactivity or restarted. For information about the lifecycle of a Neon compute, see Compute lifecycle. For information about configuring Neon's autosuspend behavior, see Autosuspend.

Database encoding

Neon does not currently support changing the database encoding. However, Neon does support ICU Custom Collations, which lets you define collation objects using ICU as the collation provider. For example:

CREATE COLLATION german (provider = icu, locale = 'de');
CREATE TABLE books (id int, title text COLLATE "german");

or

CREATE COLLATION arabic (provider = icu, locale = 'ar');
CREATE TABLE books (id int, title text COLLATE "arabic");

Event triggers

Postgres event triggers, which require Postgres superuser privileges, are currently not supported. Unlike regular triggers, which are attached to a single table and capture only DML events, event triggers are global to a particular database and are capable of capturing DDL events.

Attempting to create an event trigger will produce errors similar to these:

ERROR: permission denied to create event trigger "your_trigger_name" (SQLSTATE 42501)

ERROR:  permission denied to create event trigger "your_trigger_name"
HINT:  Must be superuser to create an event trigger.

Foreign Data Wrappers

Neon does not yet support Foreign Data Wrappers (FDW) or Postgres extensions such as postgres_fdw that provide this functionality. We intend to offer FDW support in a future release.

PostgreSQL documentation

Neon provides a mirror of the official PostgreSQL documentation on the Neon documentation site for the convenience of our users. As Neon is built on standard PostgreSQL, most information from the official PostgreSQL documentation applies to our platform. However, there are a few key differences to consider when referencing the official PostgreSQL docs:

• As a managed Postgres service, certain aspects of the official PostgreSQL documentation like installation procedures do not apply to Neon.
• Some features detailed in the official PostgreSQL documentation may not be relevant for Neon, such as those mentioned on this Postgres compatibility page.
• Features requiring the PostgreSQL superuser privilege may not be supported. See Roles and permissions above.
• Neon may not support all of the extensions mentioned in the official PostgreSQL documentation. See Postgres extensions above.