Usage metrics
This topic describes Storage, Compute, and Project usage metrics in detail so that you can better manage your plan allowances and extra usage.
Storage
Storage is the total volume of data and history stored in Neon, measured in gibibytes (GiB). It includes the following:
-
Data size
The size of all databases in your Neon projects. You can think of this as a snapshot of your data at a point in time.
-
History
Neon retains a history of changes for all branches to support point-in-time restore and branching.
-
Point-in-time restore is the ability to restore data to an earlier point in time. Neon retains a history of changes in the form of Wite-Ahead Log (WAL) records. You can configure the history retention period. See Point-in-time restore. WAL records that age out of the history retention period are evicted from storage and no longer count toward storage.
-
A branch is a virtual snapshot of your data at the point of branch creation combined with WAL records that capture the branch's data change history from that point forward. When a branch is first created, it adds no storage. No data changes have been introduced yet, and the branch's virtual snapshot still exists in the parent branch's history, which means that it shares this data in common with the parent branch. A branch begins adding to storage when data changes are introduced or when the branch's virtual snapshot falls out of the parent branch's history, in which case the branch's data is no longer shared in common. In other words, branches add storage when you modify data or allow the branch to age out of the parent branch's history.
Database branches can also share a history. For example, two branches created from the same parent at or around the same time share a history, which avoids additional storage. The same is true for a branch created from another branch. Wherever possible, Neon minimizes storage through shared history. Additionally, to keep storage to a minimum, Neon takes a new branch snapshot if the amount of data changes grows to the point that a new snapshot consumes less storage than retained WAL records.
-
Storage is calculated in gibibytes (GiB), otherwise known as binary gigabytes. One gibibyte equals 230 or 1,073,741,824 bytes.
Tips for minimizing storage
- Minimize your history retention period, which controls how much change history your project retains in the form of WAL records. On the other hand, decreasing your history retention period reduces the window available for point-in-time restore or time-travel connections. See History retention for more information.
- While it may seem counterintuitive, deleting records from a table increases storage in the short term, as those delete operations become part of your change history until they age out of your history retention window. A
DELETE TABLE
operation is more storage-efficient if you are removing all records from a table, as only this single operation would be added to your change history. - Remove or reset branches before they fall out of your history retention window. WAL records must be retained to support older branches, adding to your storage.
Compute
Compute hour usage is calculated by multiplying compute size by active hours.
Compute Hours Formula
-
A single compute hour is one active hour for a compute with 1 vCPU. For a compute with .25 vCPU, it would take 4 active hours to use 1 compute hour. On the other hand, if your compute has 4 vCPUs, it would only take 15 minutes to use 1 compute hour.
-
An active hour is a measure of the amount of time a compute is active. The time your compute is idle when suspended due to inactivity is not counted.
-
Compute size is measured at regular intervals and averaged to calculate compute hour usage. Compute size in Neon is measured in Compute Units (CUs). One CU has 1 vCPU and 4 GB of RAM. A Neon compute can have anywhere from .25 to 8 CUs, as outlined below:
Compute Units vCPU RAM .25 .25 1 GB .5 .5 2 GB 1 1 4 GB 2 2 8 GB 3 3 12 GB 4 4 16 GB 5 5 20 GB 6 6 24 GB 7 7 28 GB 8 8 32 GB -
A connection from a client or application activates a compute. Activity on the connection keeps the compute in an
Active
state. A defined period of inactivity (5 minutes by default) places the compute into anIdle
state.
How Neon compute features affect usage
Compute-hour usage in Neon is affected by autosuspend, autoscaling, and your minimum and maximum compute size configuration. With these features enabled, you can get a sense of how your compute hour usage might accrue in the following graph.
You can see how compute size scales between your minimum and maximum CPU settings, increasing and decreasing compute usage: compute size never rises above your max level, and it never drops below your minimum setting. With autosuspend, no compute time at all accrues during inactive periods. For projects with inconsistent demand, this can save significant compute usage.
note
Neon uses a small amount of compute time, included in your billed compute hours, to perform a periodic check to ensure that your computes can start and read and write data. See Availability Checker for more information.
Estimate your compute hour usage
To estimate what your compute hour usage might be per month:
-
Determine the compute size you require, in Compute Units (CUs).
-
Estimate the amount of active hours per month for your compute(s).
-
Input the values into the compute hours formula:
For example, this is a calculation for a 2 vCPU compute that is active for all hours in a month (approx. 730 hours):
This calculation is useful when trying to select the right Neon plan or when estimating the extra compute usage you might need.
note
If you plan to use Neon's Autoscaling feature, estimating compute hours is more challenging. Autoscaling adjusts the compute size based on demand within the defined minimum and maximum compute size thresholds. The best approach is to estimate an average compute size and modify the compute hours formula as follows:
To estimate an average compute size, start with a minimum compute size that can hold your data or working set (see How to size your compute). Pick a maximum compute size that can handle your peak loads. Try estimating an average compute size between those thresholds based on your workload profile for a typical day.
Projects
In Neon, everything starts with a project. A project is a container for your branches, databases, roles, and other resources and settings. A project also defines the region your data and resources reside in. We typically recommend creating a project for each application or each client. In addition to organizing objects, projects are a way to track storage and compute usage by application or client.
The following table outlines project allowances for each Neon plan.
Plan | Projects |
---|---|
Free Tier | 1 |
Launch | 10 |
Scale | 50 |
Enterprise | Unlimited |
- When you reach your limit on the Free Tier or Launch plan, you cannot create additional projects. Instead, you can upgrade to the Launch or Scale plan, which offers allowances of 10 and 50 projects, respectively.
- Extra projects are available with the Scale plan in units of 10 for $50 each.
Need help?
Join our Discord Server to ask questions or see what others are doing with Neon. Users on paid plans can open a support ticket from the console. For more detail, see Getting Support.
Last updated on