Neon is protocol and application-compatible with PostgreSQL. However, when using the Neon cloud service, there are some limitations that you should be aware of.
Neon cloud service is currently only compatible with PostgreSQL v14.
Neon cloud service does not currently provide users with access permissions other than those granted to standard database owners in PostgreSQL. Therefore, Neon users cannot access replication methods, create additional users or roles from a PostgreSQL connection, or install PostgreSQL extensions other than those permitted by Neon.
Available PostgreSQL extensions
During the Technical Preview, Neon permits installing the following PostgreSQL extensions:
|plpgsql||1.0||Pre-installed with PostgreSQL|
|postgis_tiger_geocoder||3.3.0||Cannot be installed using the Neon web UI. Use your |
Neon PostgreSQL parameter settings
The following table lists Neon PostgreSQL parameter settings that may differ from the expected default.
|fsync||off||Neon syncs data to the Neon Storage Engine to store your data safely and reliably|
|max_connections||The value depends on compute size. Set to 100 for the Technical Preview.|
|shared_buffers||The value depends on compute size|
|wal_level||replica||Logical replication is currently not supported|
Note: To increase the number of permitted connections, you can enable connection pooling. For more information, see Connection pooling.
Unlogged tables are maintained on Neon compute local storage. These tables do not survive compute restart (including when compute becomes idle). This is unlike vanilla PostgreSQL, where unlogged tables are only truncated in the event of abnormal process termination. Additionally, unlogged tables are limited by compute local storage size.
Spill and index build handling
Certain queries in PostgreSQL can generate large datasets that do not fit in memory. In such cases, storage spills the data. In Neon, the size of compute local storage limits the ability to create large indexes or execute certain queries that generate large datasets.
Temporary tables, which are stored in compute local storage, are limited by compute local storage size.
The Neon cloud service automatically closes idle connections after a period of inactivity, as described in Compute lifecycle. When connections are closed, anything defined within a session context is forgotten and must be recreated before being used again. For example, temporary tables, prepared statements, advisory locks, and notifications and listeners that were defined using the NOTIFY/LISTEN commands only exist for the duration of the current session and are lost when the session ends.
Statistics collected by the PostgreSQL cumulative statistics system are currently not saved when the Neon compute node is suspended due to inactivity or restarted. For information about the lifecycle of a Neon compute, see Compute lifecycle.