The total amount of time, measured in hours, that your compute resources have been active within a given billing period. This includes all computes in your Neon project, but excludes time when computes are in an
Idle state due to auto-suspension. The Free Tier has an Active time limit of 100 hours per month, but that limit only affects non-primary branch compute usage. Active time on all computes is counted toward the limit, but when the limit is exceeded, only non-primary branch computes are subject to suspension. The primary branch compute always remains available regardless of the limit, ensuring that access to data on the primary branch is never interrupted. Free Tier users can monitor Active time on the Usage widget on the Neon Dashboard. The Active time limit resets at the beginning of each month.
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.
See Neon API.
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.
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.
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. Neon Pro plan users can configure the Auto-suspend feature. For example, you can increase the delay period to reduce the frequency of suspensions, or you can disable Auto-suspend completely to maintain an "always-active" compute endpoint. For more information, see Edit a compute endpoint.
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.
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.
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.
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.
A copy-on-write clone of a Neon project's primary branch or previously created child branch. A branch can be created from the current or past state of the parent branch. A branch created from the current state of the parent branch includes the databases and roles that existed in the parent branch at the time of branch creation. A branch created from a past state of the parent branch includes the databases and roles that existed in the past state. The data in a branch can be modified independently from its originating data. See Branching. Connecting to a database in a branch requires connecting via the branch's compute endpoint. For more information, see Connect to a branch.
A Neon feature that allows you to create a copy-on-write clone (a "branch") of your project data. See Branch.
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.
Continuous integration and continuous delivery or continuous deployment.
Control groups, a Linux kernel feature that allows the organization, prioritization, and accounting of system resources for groups of processes.
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.
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-polished-water-579720.us-east-2.aws.neon.tech. A compute endpoint hostname includes an
ep-polished-water-579720), 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.
A method of creating a pool of connections and caching those connections for reuse. Neon supports
transaction mode for connection pooling. For more information, see Connection pooling.
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:
The compute endpoint hostname includes an
ep-polished-water-579720), a region slug (
us-east-2), the cloud platform (
aws), and Neon domain (
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.
The number of Compute Units (CU) assigned to a Neon compute. One CU is defined as having 1 vCPU with 4 GBs of RAM. A Neon compute can have anywhere from .25 CUs to 7 CUs. The number of CUs determines the processing capacity of the compute.
Compute Unit (CU)
A unit that measures the processing power of a Neon compute. A Neon compute can have anywhere from .25 CUs to 7 CUs.
A billing metric that measures the amount of computing capacity used within a given billing period. See Compute time.
See Neon Console.
The part of the Neon architecture that manages cloud storage and compute resources.
A technique used to copy data efficiently. Neon uses the copy-on-write technique to copy data when creating a 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.
A Neon Control Plane operation that creates a project with a primary branch. See Operations for more information.
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.
A billing metric that measures the total volume of data transferred out of Neon (known as "egress") during a given billing period. See Data transfer.
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
A collection of database instances, typically managed as a single entity.
Resources including compute and storage dedicated to a single Neon account.
A Neon Control Plane operation that deletes stored data when a Neon project is deleted. See Operations for more information.
The data transferred out of the Neon service to an external destination.
A custom volume-based paid plan offered by Neon. See Neon plans.
A Neon service tier for which there are no usage charges. For information about Neon’s Free Tier and associated limits, see Free Tier.
An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.
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.
A worker machine in a Kubernetes cluster, which runs containerized applications.
A component of Kubernetes that assigns newly created pods to nodes based on resource availability and other constraints.
Kernel-based Virtual Machine, a virtualization infrastructure built into the Linux kernel that allows it to act as a hypervisor for virtual machines.
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
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.
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.
Least Recently Used policy, an algorithm for cache replacement that evicts the least recently accessed items first.
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?.
The Neon RESTful Application Programming Interface. Any operation performed in the Neon Console can also be performed using the Neon API.
A browser-based graphical interface for managing Neon projects and resources.
The user account that registers and authenticates with Neon using a GitHub or Google account. After authenticating, a Neon user account can create and manage projects, branches, users, databases, and other project resources.
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.
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.
A paid Neon service tier. See Neon plans.
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 default history retention period is 7 days.
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.
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.
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 7-day history of changes for all branches in a project. The supported range is 0 to 7 days for Free Tier users, and 0 to 30 days for Pro plan users. For more information about this feature, see Branching — Point-in-time restore.
An open-source relational database management system (RDBMS) emphasizing extensibility and SQL compliance.
A Postgre role named for the registered Neon account is created with each Neon project. This user can access a Neon database from a client. 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.
Additional Postgres roles can be created in the Neon Console. You can think of a Postgres role as a "database user".
Each Neon project is created with a primary branch called
main, but you can designate any branch as your project's primary branch. The advantage of the primary branch is that its compute endpoint remains accessible if you exceed your project's limits, ensuring uninterrupted access to data that resides on the primary branch. For more information, see Primary branch.
A usage-based paid plan offered by Neon. See Neon plans.
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.
A feature that allows you to share Neon projects with other Neon users. See Share a project for more information.
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 Project storage.
A Neon component that functions as a multitenant service that accepts and handles connections from clients that use the Postgres protocol.
A Neon feature that allows you to connect to a Neon project with a single
psql command. See Passwordless auth.
A free and open-source emulator and virtualizer that performs hardware virtualization.
Random Access Memory, a type of computer memory used to store data that is being actively processed.
The geographic location where Neon project resource are located. Neon supports creating projects in several Amazon Web Services (AWS) regions. For information about regions supported by Neon, see Regions.
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.
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 refers to Neon's Auto-suspend compute 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 Auto-suspend compute.
A cloud-based development model that enables developing and running applications without having to manage servers.
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.
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.
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.
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.
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.
Neon is currently in Technical Preview, meaning that some intended core functionalities are still being developed or perfected. Please refer to the Neon roadmap for more information.
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.
A temporary file storage system that uses a portion of a system's RAM to store files, improving performance by reducing disk usage.
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.
Virtual CPU, a unit of processing power allocated to a virtual machine or compute instance.
See Write-Ahead Logging.
Write-ahead logs in a specific LSN range.
The stream of data written to the Write-Ahead Log (WAL) during transactional processing.
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.
A billing metric that measures the total volume of data written from compute to storage within a given billing period, measured in gigibytes (GiBs). Writing data from compute to storage ensures the durability and integrity of your data. See Written data.