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 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 System operations for more information.

Archive storage

Cost-efficient storage where Neon archives inactive branches after a defined threshold. For Neon projects created in AWS regions, inactive branches are archived in Amazon S3 storage. For Neon projects created in Azure regions, branches are archived in Azure Blob storage.

Autosuspend

A feature that suspends a compute after a specified period of inactivity (5 minutes, by default) to minimize compute usage. This feature is also referred to as "scale to zero". When suspended, a compute is placed into an Idle state. Otherwise, the compute 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 to maintain an "always-active" compute. For more information, see Edit a compute.

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 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. You can monitor these checks, how long they take, and how often they occur, on the Systems operations tab on the Monitoring page in the Neon Console.

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 attached to the branch. See Connect to a branch.

branch archiving

The automatic archiving of inactive branches in cost-efficient archive storage after a defined threshold. For more, see Branch archiving.

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.

Business plan

A paid plan offered by Neon designed for mid-to-large enterprises that require higher compute capacity and advanced security and compliance features. See Neon plans.

check_availability

A Neon Control Plane operation that checks the availability of data in a branch and that a compute can start on a branch. Branches without a compute are not checked. This operation, performed by the availability checker, is a periodic load generated by the Control Plane. You can monitor these checks, how long they take, and how often they occur, on the Systems operations tab on the Monitoring page in the Neon Console.

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, including CPU, memory, and storage, for running applications. In the context of Neon, a compute runs Postgres.

Neon creates a primary read-write compute for the project's default branch. Neon supports both read-write and read replica computes. A branch can have a single primary (read-write) compute but supports multiple read replica computes. The compute hostname is required to connect to a Neon Postgres database from a client or application. A compute endpoint is the access point through which users connect to a Neon compute.

compute endpoint

The access point through which users connect to a Neon compute. In the context of Neon, the compute endpoint is represented by a connection string, which includes necessary credentials and connection parameters. This connection string enables clients, such as applications or users, to securely connect to a Postgres database running on a Neon compute. See connection string.

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 Postgres database. The details include a user name (role), compute hostname, and database name; for example:

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

The compute 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 10 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 10 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 Plan, 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 = compute size * active hours

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 System operations for more information.

create_timeline

Sets up storage and creates the default branch when a Neon project is created. See System 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. Neon does not charge for egress data, but we limit the amount of egress available on Free Plan projects to 5 GB per month. See Data tranfser.

Database

A named collection of database objects. A Neon project is created with a database that resides in the default public schema. If you do not specify a name for the database when creating a Noen project, it's created with the name neondb. 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 System operations for more information.

Endpoint ID

A string that identifies a Neon compute. Neon Endpoint IDs are generated Heroku-like memorable random names, similar to ep-calm-flower-a5b75h79. These names are always prefixed by ep for "endpoint". You can find your Endpoint ID by navigating to your project in the Neon Console, selecting Branches from the sidebar, and clicking on a branch. The Endpoint ID is shown in the table under the Computes heading.

Egress

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

Enterprise plan

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

Free Plan

See Neon Free Plan.

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 Business plan feature that can be used to control access to the branch where your database resides. 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.

Launch plan

A paid plan offered by Neon that provides all of the resources, features, and support you need to launch your application. It's ideal for startups and growing businesses or applications. See Neon plans.

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. 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.

Monitoring Dashboard

A feature of the Neon Console that provides several graphs to help you monitor system and database metrics, updated in real time based on your usage data.

Neon

A serverless Postgres platform designed to help developers build reliable and scalable applications faster. We separate compute and storage to offer modern developer features such as autoscaling, branching, point-in-time restore, and more. For more information, see Why 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 Plan

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

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-default branch

Any branch in a Neon project that is not designated as the default branch. For more information, see Non-default 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 plan. 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.

peak usage

Peak usage is the highest amount of a resource (like storage or projects) you’ve used during the current billing period. If you go over your plan’s limit, extra charges are added in set increments. You’re charged for these extra units from the date you went over the limit, with the charges prorated for the rest of the month.

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 point. 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 1 day across all plans to help avoid unexpected storage costs. You can increase the retention window to 24 hours for Neon Free Plan users, 7 days for Launch, 14 days for Scale, and 30 days for Business plan users. Keep in mind that this will increase your storage usage and may lead to higher costs, especially if you have many active branches.

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:

postgresql://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 How to use 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.

default 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 default branch designation by default.

The default branch has a larger compute hour allowance on the Free Plan. For users on paid plans, the compute associated with the default branch is exempt from the limit on simultaneously active computes, ensuring that it is always available.

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

For more information, see default 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 ID

A string that identifies your Neon project. Neon Project IDs are generated Heroku-like memorable random names, similar to cool-forest-86753099. You can find your project ID by navigating to your project in the Neon Console and selecting Settings from the sidebar. The project ID is also visible in the Neon Console URL after navigating to a project: https://console.neon.tech/app/projects/cool-forest-86753099

Project Collaboration

A feature that allows you to invite other Neon users to collaborate on your Neon projects. See Invite collaborators 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

You can designate any Neon branch as a "protected branch", which implements a series of protections:

• Protected branches cannot be deleted.
• Protected branches cannot be reset.
• Projects with protected branches cannot be deleted.
• Computes associated with a protected branch cannot be deleted.
• New passwords are automatically generated for Postgres roles on branches created from protected branches.
• With additional configuration steps, you can apply IP restrictions to protected branches only. The IP Allow feature is only available on Neon's Business plan.

The protected branches feature is available on all Neon paid plans. Typically, the protected branch status is given to a branch or branches that hold production data or sensitive data. For information about how to configure a protected branch, refer to our 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 Amazon Web Services (AWS) and Azure 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 default branch of your Neon project by default. You can change your project's default 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 into an Idle state when it is not being used. Neon suspends a compute after five minutes of inactivity, by default. See Autosuspend.

Scale plan

A paid plan offered by Neon that provides full platform and support access. It's designed for scaling production workloads. See Neon plans.

Schema Diff

A Neon feature that lets you compare database schemas between different branches for better debugging, code review, and team collobration. See Schema Diff.

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 when there is an event or action that requires compute resources. For example, connecting to a suspended compute initiates this operation. See System 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 after a period of inactivity. See System 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.

tenant_attach

A Neon Control Plane operation that attaches a Neon project to storage. For example, this operation occurs when when you create a new Neon project. See System operations for more information.

tenant_detach

A Neon Control Plane operation that detaches a Neon project from storage. For example, this operation occurs after the project as been idle for 30 days. See System operations for more information.

tenant_reattach

A Neon Control Plane operation that reattaches a Neon project to storage. For example, this operation occurs when a detached Neon project receives a request. See System operations for more information.

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:

postgresql://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.

Time Travel

A Neon feature that lets you connect to any selected point in time within your history retention window and run queries against that connection. See Time Travel.

user

See Neon user and Postgres role.

vm-monitor

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.

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.