Glossary

Access token

See Token.

Active hours

A usage metric that tracks the amount of time a compute is active, rather than idle when suspended due to inactivity. The time that your compute is idle is not counted toward compute usage.

Also see Compute hours.

Activity Monitor

A process that monitors a Neon compute instance for activity. During periods of inactivity, the Activity Monitor gracefully places the compute into an Idle state to save energy and resources. The Activity Monitor closes idle connections after 5 minutes of inactivity. When a connection is made to an idle compute, the Activity Monitor reactivates the compute.

API

See Neon API.

API Key

A unique identifier used to authenticate a user or a calling program to an API. An API key is required to authenticate to the Neon API. For more information, see Manage API keys.

apply_config

A Neon Control Plane operation that applies a new configuration to a Neon object or resource. For example, creating, deleting, or updating Postgres users and databases initiates this operation. See Operations for more information.

Autosuspend compute

A feature that suspends a compute endpoint after a specified period of inactivity (5 minutes, by default) to save on compute resources. This feature is also referred to as "scale to zero". When suspended, a compute endpoint is placed into an Idle state. Otherwise, the compute endpoint is in an Active state. Users on paid plans can configure the Autosuspend feature. For example, you can increase the delay period to reduce the frequency of suspensions, or you can disable autosuspend completely to maintain an "always-active" compute endpoint. For more information, see Edit a compute endpoint.

autoscaler-agent

A control mechanism in the Neon autoscaling system that collects metrics from VMs, makes scaling decisions, and performs checks and requests to implement those decisions.

Autoscaling

A feature that automatically adjusts the allocation of vCPU and RAM for compute endpoints within specified minimum and maximum compute size boundaries, optimizing for performance and cost-efficiency. For information about how Neon implements the Autoscaling feature, see Autoscaling.

Availability Checker

A periodic load generated by the Control Plane to determine if a compute can start and read and write data. The Availability Checker queries a system database without accessing user data.

Backpressure

A mechanism that manages the lag between the Pageserver and compute node or the Pageserver and Write-Ahead Log (WAL) service. If the WAL service runs ahead of the Pageserver, the time to serve page requests increases, which could result in increased query times or timeout errors. The backpressure mechanism manages lag using a stop-and-wait backend throttling strategy.

Branch

An isolated copy of data, similar to a Git branch. Data includes databases, schemas, tables, records, indexes, roles — everything that comprises data in a Postgres instance. Just as a Git branch allows developers to work on separate features or fixes without impacting their main line of code, a Neon branch enables users to modify a copy of their data in isolation from their main line of data. This approach facilitates parallel database development, testing, and other features, similar to Git's code branching system.

Each Neon project is created with a main line of data referred to as the root branch. A branch created from the root branch or another branch is a copy-on-write clone.

You can create a branch from the current or past state of another branch. A branch created from the current state of another branch includes the data that existed on that branch at the time of branch creation. A branch created from a past state of another branch includes the data that existed in the past state.

Connecting to a database on a branch requires connecting via a compute endpoint attached to the branch. See Connect to a branch.

Branching

A Neon feature that allows you to create an isolated copy of your data for parallel database development, testing, and other purposes, similar to branching in Git. See Branch.

check_availability

A Neon Control Plane operation that checks the availability of data in a branch and that a compute endpoint can start on a branch. Branches without a compute endpoint are not checked. This operation, performed by the availability checker, is a periodic load generated by the Control Plane. See Operations for more information.

CI/CD

Continuous integration and continuous delivery or continuous deployment.

CIDR notation

CIDR (Classless Inter-Domain Routing) notation is a method used to define ranges of IP addresses in network management. It is presented in the format of an IP address, followed by a slash, and then a number (e.g., 203.0.113.0/24). The number after the slash represents the size of the address block, providing a compact way to specify a large range of IP addresses. In Neon's IP Allow feature, CIDR notation allows for efficiently specifying a block of IP addresses, especially useful for larger networks or subnets. This can be advantageous when managing access to branches with numerous potential users, such as in a large development team or a company-wide network. For related information, see Configure IP Allow.

cgroups

Control groups, a Linux kernel feature that allows the organization, prioritization, and accounting of system resources for groups of processes.

Compute

A service that provides virtualized computing resources (CPU, memory, and storage) for running applications. A Neon compute instance (also referred to as a compute endpoint) runs Postgres. The amount of compute resources available to a Neon project is defined by tier. Neon supports free and paid tiers.

Compute endpoint

A Neon compute instance. Neon creates a single read-write compute endpoint for the project's primary branch. Neon supports both read-write and read-only compute endpoints. Read-only compute endpoints are also referred to as Read replicas. A branch can have a single read-write compute endpoint but supports multiple read-only compute endpoints. You can choose whether or not to create a compute endpoint when creating child branches. The compute endpoint hostname is required to connect to a Neon database from a client or application. A compute endpoint hostname can be found in the Connection Details widget on the Neon Dashboard or by selecting the branch on the Branches page in the Neon Console. A compute endpoint hostname starts with an ep- prefix, as in this example: ep-cool-darkness-123456.us-east-2.aws.neon.tech. A compute endpoint hostname includes an endpoint_id (ep-cool-darkness-123456), a region slug (us-east-2), the cloud platform (aws), and Neon domain (neon.tech). For information about connecting to Neon, see Connect from any application. For more information about compute endpoints, see Manage computes.

Connection pooling

A method of creating a pool of connections and caching those connections for reuse. Neon supports PgBouncer in transaction mode for connection pooling. For more information, see Connection pooling.

Connection string

A string containing details for connecting to a Neon database. The details include a user name (role), compute endpoint hostname, and database name; for example:

postgres://alex:AbC123dEf@ep-cool-darkness-123456.us-east-2.aws.neon.tech/dbname

The compute endpoint hostname includes an endpoint_id (ep-cool-darkness-123456), a region slug (us-east-2), the cloud platform (aws), and Neon domain (neon.tech).

Connection strings for a Neon databases can be obtained from the Connection Details widget on the Neon Dashboard. For information about connecting to Neon, see Connect from any application.

Compute size

The Compute Units (CU) that are allocated to a Neon compute. A Neon compute can have anywhere from .25 to 8 CU. The number of units determines the processing capacity of the compute.

Compute Unit (CU)

A unit that measures the processing power or "size" of a Neon compute. A Compute Unit (CU) includes vCPU and RAM. A Neon compute can have anywhere from .25 to 8 CUs. The following table shows the vCPU and RAM for each CU:

Compute hours

A usage metric for tracking compute usage. 1 compute hour is equal to 1 active hour for a compute with 1 vCPU. If you have a compute with .25 vCPU, as you would on the Neon Free Tier, it would require 4 active hours to use 1 compute hour. On the other hand, if you have a compute with 4 vCPU, it would only take 15 minutes to use 1 compute hour.

To calculate compute hour usage, you would use the following formula:

compute hours = active hours x compute size

For more information, see Compute.

Also see Active hours.

Console

See Neon Console.

Control Plane

The part of the Neon architecture that manages cloud storage and compute resources.

Copy-on-write

A technique used to copy data efficiently. Neon uses the copy-on-write technique when creating branches. When a branch is created, data is marked as shared rather than physically duplicated. Parent and child branches refer to the same physical data resource. Data is only physically copied when a write occurs. The affected portion of data is copied and the write is performed on the copied data.

create_branch

A Neon Control Plane operation that creates a branch in a Neon project. For related information, see Manage branches. See Operations for more information.

create_timeline

A Neon Control Plane operation that creates a project with a root branch. See Operations for more information.

Data-at-rest encryption

A method of storing inactive data that converts plaintext data into a coded form or cipher text, making it unreadable without an encryption key. Neon stores inactive data in NVMe SSD volumes. The data on NVMe instance storage is encrypted using an XTS-AES-256 block cipher implemented in a hardware module on the instance.

Data transfer

A usage metric that measures the total volume of data transferred out of Neon (known as "egress") during a given billing period.

Database

A named collection of database objects. A Neon project has a ready-to-use database named neondb which resides in the default public schema. A Neon project can contain multiple databases. Users cannot manipulate system databases, such as the postgres, template0, or template1 databases.

Database branching

See Branching.

Database fleet

A collection of database instances, typically managed as a single entity.

Decoder plugin

Utilized in PostgreSQL replication architecture to decode WAL entries into a format understandable by the subscriber. The pgoutput decoder plugin is the default decoder, with alternatives like wal2json for specific use cases. Neon supports pgoutput and wal2json. See Postgres logical replication concepts.

Dedicated resources

Resources including compute and storage dedicated to a single Neon account.

delete_tenant

A Neon Control Plane operation that deletes stored data when a Neon project is deleted. See Operations for more information.

Egress

The data transferred out of the Neon service to an external destination.

Enterprise plan

A custom volume-based paid plan offered by Neon. See Neon plans.

Free Tier

See Neon Free Tier.

History

The history of data changes for all branches in your Neon project. A history is maintained to support point-in-time restore. For more information, see Storage details.

IP allowlist

An IP allowlist is a security measure used in network and database management. It specifies a list of IP addresses that are permitted to access a certain resource. Any IP address not on the list is automatically blocked, ensuring that only authorized users or systems can gain access. In Neon, IP Allow is a Scale plan feature that can be used to control access to the branch where your database resides. The allowlist can be applied to all branches (the default) or the primary branch only. For more information, see Configure the IP Allow list.

Kubernetes

An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.

Kubernetes cluster

A set of interconnected nodes that run containerized applications and services using Kubernetes, an open-source orchestration platform for automating deployment, scaling, and management of containerized applications. The cluster consists of at least one control plane node, which manages the overall state of the cluster, and multiple worker nodes, where the actual application containers are deployed and executed. The worker nodes communicate with the control plane node to ensure the desired state of the applications is maintained.

Kubernetes node

A worker machine in a Kubernetes cluster, which runs containerized applications.

Kubernetes scheduler

A component of Kubernetes that assigns newly created pods to nodes based on resource availability and other constraints.

KVM

Kernel-based Virtual Machine, a virtualization infrastructure built into the Linux kernel that allows it to act as a hypervisor for virtual machines.

Live migration

A feature provided by some hypervisors, such as QEMU, that allows the transfer of a running virtual machine from one host to another with minimal interruption.

Local File Cache

The Local File Cache (LFC) is a layer of caching that stores frequently accessed data from the storage layer in the local memory of the compute instance. This cache helps to reduce latency and improve query performance by minimizing the need to fetch data from the storage layer repeatedly. The LFC acts as an add-on or extension of Postgres shared buffers. In Neon the shared_buffers setting is always 128 MB, regardless of compute size. The LFC extends cache memory up to 80% of your compute's RAM.

Logical data size

For a Postgres database, it is the size of the database, including all tables, indexes, views, and stored procedures. In Neon, a branch can have multiple databases. The logical data size for a branch is therefore equal to the total logical size of all databases on the branch.

Logical replication

A method of replicating data between databases or platforms, focusing on replicating transactional changes (like INSERT, UPDATE, DELETE) rather than the entire database, enabling selective replication of specific tables or rows. Neon supports logical replication of data to external destinations. See Logical replication.

LSN

Log Sequence Number. A byte offset to a location in the WAL stream. The Neon branching feature supports creating branches with data up to a specified LSN.

LRU policy

Least Recently Used policy, an algorithm for cache replacement that evicts the least recently accessed items first.

Neon

A fully managed serverless Postgres. Neon separates storage and compute to offer modern developer features such as branching, autoscaling, and bottomless storage. For more information, see What is Neon?.

Neon API

The Neon RESTful Application Programming Interface. Any operation performed in the Neon Console can also be performed using the Neon API.

Neon Console

A browser-based graphical interface for managing Neon projects and resources.

Neon Free Tier

A Neon service tier for which there are no usage charges. For information about the Neon Free Tier and associated limits, see Neon Free Tier.

Neon user

The user account that registers and authenticates with Neon using an email, GitHub, Google, or partner account. After authenticating, a Neon user account can create and manage projects, branches, users, databases, and other project resources.

NeonVM

A QEMU-based tool used by Neon to create and manage VMs within a Kubernetes cluster, allowing for the allocation and deallocation of vCPU and RAM. For more information, refer to the NeonVM source in the neondatabase/autoscaling repository.

Non-primary branch

Any branch in a Neon project that is not designated as the primary branch. For more information, see Non-primary branch.

Page

An 8KB unit of data, which is the smallest unit that Postgres uses for storing relations and indexes on disk. In Neon, a page is also the smallest unit of data that resides on a Pageserver. For information about Postgres page format, see Database Page Layout, in the PostgreSQL Documentation.

Paid plan

A paid Neon service tier. See Neon plans.

Pageserver

A Neon architecture component that reads WAL records from Safekeepers to identify modified pages. The Pageserver accumulates and indexes incoming WAL records in memory and writes them to disk in batches. Each batch is written to an immutable file that is never modified after creation. Using these files, the Pageserver can quickly reconstruct any version of a page dating back to the defined history retention period. Neon retains a history for all branches.

The Pageserver uploads immutable files to cloud storage, which is the final, highly durable destination for data. After a file is successfully uploaded to cloud storage, the corresponding WAL records can be removed from the Safekeepers.

Passwordless authentication

The ability to authenticate without providing a password. Neon’s Passwordless auth feature supports passwordless authentication.

Platform Partnership plan

A custom volume-based paid plan offered by Neon that includes support for resale. See Neon plans.

Point-in-time restore

Restoration of data to a state that existed at an earlier time. Neon retains a history of changes in the form of Write-Ahead-Log (WAL) records, which allows you to restore data to an earlier time. A point-in-time restore is performed by creating a branch using the Time or LSN option. By default, Neon retains a history of changes for all branches in a project. The supported limits are 24 hours for Neon Free Tier users, 7 days for Launch plan users, and 30 days for Scale plan users. For more information about this feature, see Branching — Point-in-time restore.

pooled connection string

A pooled connection string in Neon includes a -pooler option, which directs your connection to a pooled connection port at the Neon Proxy. This is an example of a pooled connection:

postgres://alex:AbC123dEf@ep-cool-darkness-123456-pooler.us-east-2.aws.neon.tech/dbname

A pooled connection can support a high number of concurrent users and is recommended for use with serverless and edge functions. For more information, see Connection pooling.

You can obtain a pooled connection string for your database from the Connection Details widget on the Neon Dashboard. Select the Pooled connection option to add the -pooler option to the connection string. For further instructions, see Enable connection pooling.

PostgreSQL

An open-source relational database management system (RDBMS) emphasizing extensibility and SQL compliance.

Postgres role

A Postgres role named for the registered Neon account is created with each Neon project. This role and any additional role created in the Neon Console, API, or CLI is assigned the neon_superuser role, which allows creating databases, roles, and reading and writing data in all tables, views, sequences. Roles created with SQL are created with the same basic public schema privileges granted to newly created roles in a standalone Postgres installation. These users are not assigned the neon_superuser role. They must be selectively granted permissions for each database object. For more information, see Manage database access.

Older projects may have a web-access system role, used by the SQL Editor and Neon’s Passwordless auth. The web-access role is system-managed. It cannot be modified, removed, or used in other authentication scenarios.

Primary branch

A designation that is given to a single branch in a Neon project. Each Neon project is created with a root branch called main, which carries the primary branch designation by default.

The compute endpoint associated with a primary branch remains available if you exceed your project's limits, ensuring uninterrupted access to data that resides on the primary branch.

You can change your primary branch, but a branch carrying the primary branch designation cannot be deleted.

For more information, see Primary branch.

Project

A collection of branches, databases, roles, and other project resources and settings. A project contains a compute with a Postgres server and storage for the project data.

Project sharing

A feature that allows you to share Neon projects with other Neon users. See Share a project for more information.

Project storage

The total volume of data stored in your Neon project. Also, a billing metric that measures the total volume of data and history, in GiB-hours, stored in your Neon project. See Storage.

Prorate

Adjusting a payment or charge so it corresponds to the actual usage or time period involved, rather than charging a full amount. Neon prorates the cost for extra units of storage when you exceed your plan's allowance. For example, if you purchase an extra unit of storage halfway through the monthly billing period, you are only charged half the unit price.

Proxy

A Neon component that functions as a multitenant service that accepts and handles connections from clients that use the Postgres protocol.

Protected branch

A status assigned to a branch that limits access based on IP addresses. Only IPs listed in the project’s IP allowlist can access this branch. Typically, the protected branch status is given to a branch or branches that hold production data or sensitive data. The protected branch feature is available on Neon's Scale plan. For information about how to configure a protected branch, refer to the Protected branches guide.

Publisher

In the context of logical replication, the publisher is the primary data source where changes occur. It's responsible for sending those changes to one or more subscribers. A Neon database can act as a publisher in a logical replication setup. See Logical replication.

QEMU

A free and open-source emulator and virtualizer that performs hardware virtualization.

RAM

Random Access Memory, a type of computer memory used to store data that is being actively processed.

Region

The geographic location where Neon project resources are located. Neon supports creating projects in several Amazon Web Services (AWS) regions. For information about regions supported by Neon, see Regions.

Replication slot

On the publisher database in a logical replication setup, replication slots track the progress of replication to ensure no data in the WAL is purged before the subscriber has successfully replicated it, thus preventing data loss or inconsistency. See Postgres logical replication concepts.

Resale

Selling the Neon service as part of another service offering. Neon's Platform Partnership plan offers resale of the Neon service as an option. See Neon plans for more information.

Root branch

The primary line of data for every Neon project, initially named main. The root branch cannot be deleted and is set as the primary branch of your Neon project by default. You can change your project's primary branch, but you cannot change the root branch.

Safekeeper

A Neon architecture component responsible for the durability of database changes. Postgres streams WAL records to Safekeepers. A quorum algorithm based on Paxos ensures that when a transaction is committed, it is stored on a majority of Safekeepers and can be recovered if a node is lost. Safekeepers are deployed in different availability zones to ensure high availability and durability.

Scale-to-zero

Scale-to-zero refers to Neon's Autosuspend feature, which places a compute endpoint into an Idle state when it is not being used. Neon suspends a compute after five minutes of inactivity, by default. See Autosuspend compute.

Serverless

A cloud-based development model that enables developing and running applications without having to manage servers.

shared buffers

A memory area in Postgres for caching blocks of data from storage (disk on standalone Postgres or Pageservers in Neon). This cache enhances the performance of database operations by reducing the need to access the slower storage for frequently accessed data. Neon uses a Local File Cache (LFC), which acts as an add-on or extension of shared buffers. In Neon the shared_buffers setting is always 128 MB, regardless of compute size. The LFC extends cache memory up to 80% of your compute's RAM. For additional information about shared buffers in Postgres, see Resource Consumption, in the Postgres documentation.

SNI

Server Name Indication. A TLS protocol extension that allows a client or browser to indicate which hostname it wants to connect to at the beginning of a TLS handshake.

SQL Editor

A feature of the Neon Console that enables running queries on a Neon database. The SQL Editor also enables saving queries, viewing query history, and analyzing or explaining queries.

start_compute

A Neon Control Plane operation that starts a compute endpoint when there is an event or action that requires compute resources. For example, connecting to a suspended compute endpoint initiates this operation. See Operations for more information. For information about how Neon manages compute resources, see Compute lifecycle.

Storage

Where data is recorded and stored. Neon storage consists of Pageservers, which store hot data, and a cloud object store, such as Amazon S3, that stores cold data for cost optimization and durability.

Also, a usage metric that tracks the total volume of data and history stored in Neon. For more information, see Storage.

Subscriber

The database or platform receiving changes from the publisher in a logical replication setup. It applies changes received from the publisher to its own data set. Currently, a Neon database can only act as a publisher in a logical replication setup. See Logical replication.

Subscription

Represents the downstream side of logical replication, establishing a connection to the publisher and subscribing to one or more publications to receive updates. See Postgres logical replication concepts.

suspend_compute

A Neon Control Plane operation that suspends a compute endpoint after a period of inactivity. See Operations for more information. For information about how Neon manages compute resources, see Compute lifecycle.

Technical preview

An early version of a feature or changes released for testing and feedback purposes.

Token

An encrypted access token that enables you to authenticate with Neon using the Neon API. An access token is generated when creating a Neon API key. For more information, see Manage API keys.

unpooled connection string

An unpooled connection string connects to your Neon database directly. It does not use connection pooling, and it looks similar to this:

postgres://alex:AbC123dEf@ep-cool-darkness-123456.us-east-2.aws.neon.tech/dbname

You can obtain an unpooled connection string for your database from the Connection Details widget on the Neon Dashboard. Ensure that the Pooled connection option is not selected. A direct connection is subject to the max_connections limit for your compute. For more information, see How to size your compute.

User

See Neon user and Postgres role.

vm-informant

A program that runs inside the VM alongside Postgres, responsible for requesting more resources from the autoscaler-agent and validating proposed downscaling to ensure sufficient memory.

vCPU

Virtual CPU, a unit of processing power allocated to a virtual machine or compute instance.

WAL

See Write-Ahead Logging.

WAL receiver

In logical replication, on the subscriber side, the WAL receiver is a process that receives the replication stream (decoded WAL data) and applies these changes to the subscriber's database. See Postgres logical replication concepts.

WAL sender

In logical replication, the WAL sender is a process on the publisher database that reads the WAL and sends relevant data to the subscriber. See Postgres logical replication concepts.

WAL slice

Write-ahead logs in a specific LSN range.

WAL stream

The stream of data written to the Write-Ahead Log (WAL) during transactional processing.

Working set

A subset of frequently accessed or recently used data and indexes that ideally reside in memory (RAM) for quick access, allowing for better performance. See how to size your compute to learn how to set your minimum compute to an adequate size to handle your working set.

Write-Ahead Logging (WAL)

A standard mechanism that ensures the durability of your data. Neon relies on WAL to separate storage and compute, and to support features such as branching and point-in-time restore.

In logical replication, the WAL records all changes to the data, serving as the source for data that needs to be replicated.

Written data

A usage metric that measures the total volume of data written from compute to storage within a given billing period, measured in gigibytes (GiB). Writing data from compute to storage ensures the durability and integrity of your data.