neondatabase · voolga · Jun 1, 2026 · Jun 1, 2026 · Jun 1, 2026 · Jun 4, 2026
@@ -6,7 +6,7 @@ summary: >-
   magic links, and verification emails — by intercepting delivery events with
   webhooks and sending them through your own email provider.
 enableTableOfContents: true
-updatedOn: '2026-05-27T07:50:31.326Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <FeatureBetaProps feature_name="Neon Auth with Better Auth" />

@@ -6,7 +6,7 @@ summary: >-
   sign in, reset passwords, and verify email addresses using one-time passwords
   sent via email, with automatic handling of OTP generation and delivery.
 enableTableOfContents: true
-updatedOn: '2026-05-15T10:42:42.837Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <FeatureBetaProps feature_name="Neon Auth with Better Auth" />

@@ -5,7 +5,7 @@ summary: >-
   Configure webhooks to receive notifications for authentication events like OTP
   delivery, magic link delivery, and user creation in Neon Auth.
 enableTableOfContents: true
-updatedOn: '2026-05-29T09:07:33.053Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <FeatureBetaProps feature_name="Neon Auth with Better Auth" />

@@ -6,7 +6,7 @@ summary: >-
   application with Neon Auth, including trusted domains, custom email providers,
   OAuth credentials, email verification, and security measures.
 enableTableOfContents: true
-updatedOn: '2026-05-15T10:42:42.837Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <FeatureBetaProps feature_name="Neon Auth with Better Auth" />

@@ -5,7 +5,7 @@ summary: >-
   How to connect your Neon Postgres database to Looker Studio by configuring the
   PostgreSQL data source, setting up SSL, and authenticating the connection.
 enableTableOfContents: true
-updatedOn: '2026-06-03T08:48:52.419Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 [Looker Studio](https://lookerstudio.google.com/) is Google's data visualization and business intelligence platform. This guide explains how to connect your Neon Postgres database to Looker Studio using a PostgreSQL data source.

@@ -6,7 +6,7 @@ summary: >-
   metrics and Postgres logs to monitor database performance and resource
   utilization directly within Datadog's observability platform.
 enableTableOfContents: true
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <InfoBlock>

@@ -6,7 +6,7 @@ summary: >-
   configuration for log forwarding and the transmission of metrics related to
   database performance and resource utilization.
 enableTableOfContents: true
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <InfoBlock>

@@ -8,7 +8,7 @@ summary: >-
 enableTableOfContents: true
 redirectFrom:
   - /docs/guides/neon-private-access
-updatedOn: '2026-04-29T16:04:30.000Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 <Admonition type="comingSoon" title="Private Networking availability">

@@ -6,7 +6,7 @@ summary: >-
   usage, including right-sizing, effective autoscaling, enabling scale to zero,
   and managing persistent connections.
 enableTableOfContents: true
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 Managing your Neon costs effectively requires understanding how each billing factor works and implementing strategies to control usage. This guide provides actionable recommendations for optimizing costs across all billing metrics.

@@ -7,7 +7,7 @@ summary: >-
   Neon, including the egress optimizer agent skill, public and private transfer
   types, common causes of high usage, Console and API monitoring, and strategies
   to reduce transfer.
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 Network transfer is one of the usage metrics that affects your Neon bill. This guide explains what network transfer is, what causes it to increase, how to monitor it, and how to reduce it. For broader cost guidance, see [Cost optimization](/docs/introduction/cost-optimization). For plan allowances and pricing, see [Plans](/docs/introduction/plans).

@@ -19,7 +19,7 @@ redirectFrom:
   - /docs/reference/billing-sample
   - /docs/introduction/legacy-plans
   - /docs/introduction/extra-usage
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 Neon offers plans to support you at every stage, from your first prototype to production at scale.

@@ -7,7 +7,7 @@ enableTableOfContents: true
 isDraft: false
 redirectFrom:
   - /docs/conceptual-guides/regions
-updatedOn: '2026-05-07T18:15:13.000Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 Neon offers project deployment in multiple AWS and Azure regions. To minimize latency between your Neon database and application, we recommend choosing the region closest to your application server.
@@ -58,7 +58,7 @@ If you are unsure of your project's region, you can find this information in the
 | `aws-us-east-1`      | 100.26.142.14, 100.51.56.234, 13.219.161.141, 18.211.255.174, 18.215.104.21, 23.23.0.232, 3.213.105.99, 3.222.32.110, 34.202.217.219, 34.224.137.41, 34.233.170.231, 34.235.208.71, 34.239.66.10, 35.168.244.148, 44.209.63.35, 44.212.197.226, 52.203.31.78, 52.70.189.141, 52.73.235.120, 54.156.66.192, 54.160.39.37, 54.173.116.247, 54.197.227.141, 54.205.208.153, 54.88.155.118, 98.88.203.121, 98.88.212.99 |
 | `aws-us-east-2`      | 16.58.110.124, 16.58.110.255, 16.58.110.55, 18.116.233.216, 18.117.39.4, 18.217.181.229, 3.128.125.142, 3.128.6.252, 3.129.145.179, 3.139.195.115, 3.139.7.20, 3.16.227.37, 52.15.165.218                                                                                                                                                                                                                           |
 | `aws-us-west-2`      | 34.213.87.149, 35.164.221.218, 35.83.202.11, 44.235.241.217, 44.236.56.140, 52.32.22.241, 52.37.48.254, 52.40.99.9, 54.186.210.201, 54.213.57.47                                                                                                                                                                                                                                                                    |
-| `aws-eu-central-1`   | 18.156.24.144, 18.158.63.175, 18.194.181.241, 18.198.137.195, 3.123.76.138, 3.125.234.79, 3.125.57.42, 3.66.63.165, 52.58.17.95, 54.93.82.216, 63.181.53.159, 63.184.85.228 |
+| `aws-eu-central-1`   | 18.156.24.144, 18.158.63.175, 18.194.181.241, 18.198.137.195, 3.123.76.138, 3.125.234.79, 3.125.57.42, 3.66.63.165, 52.58.17.95, 54.93.82.216, 63.181.53.159, 63.184.85.228                                                                                                                                                                                                                                         |
 | `aws-eu-west-2`      | 18.133.205.39, 3.10.42.8, 52.56.191.86                                                                                                                                                                                                                                                                                                                                                                              |
 | `aws-ap-southeast-1` | 3.1.239.32, 47.131.90.115, 52.76.51.78, 54.254.50.26, 54.254.92.70, 54.255.161.23                                                                                                                                                                                                                                                                                                                                   |
 | `aws-ap-southeast-2` | 13.237.134.148, 13.55.152.144, 54.153.185.87                                                                                                                                                                                                                                                                                                                                                                        |

@@ -9,7 +9,7 @@ redirectFrom:
   - /docs/cloud/roadmap
   - /docs/conceptual-guides/roadmap
   - /docs/reference/roadmap
-updatedOn: '2026-06-03T10:32:16.640Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 This roadmap describes what's in flight, what we delivered recently, and what's on the horizon.

@@ -6,7 +6,7 @@ summary: >-
   byte-hours and CU-seconds into human-readable billing units, and calculate
   costs using plan rates and allowances.
 enableTableOfContents: true
-updatedOn: '2026-05-29T16:16:59.299Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 This guide helps you use the Neon API to fetch your consumption data, convert raw metrics into human-readable numbers, and understand how your bill is calculated. To monitor usage in the Neon Console instead, see [Monitor billing and usage](/docs/introduction/monitor-usage).

@@ -6,7 +6,7 @@ summary: >-
   projects, including listing, creating, updating, deleting, and retrieving
   project information directly from the terminal.
 enableTableOfContents: true
-updatedOn: '2026-06-03T10:16:42.918Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 ## Before you begin

@@ -6,7 +6,7 @@ summary: >-
   observability platforms, detailing available metrics, their labels, and
   integration specifics with tools like Datadog and Grafana Cloud.
 enableTableOfContents: true
-updatedOn: '2026-05-29T00:27:59.360Z'
+updatedOn: '2026-06-04T11:16:32.279Z'
 ---
 
 This page provides a comprehensive reference for all metrics and log fields that Neon exports to observability platforms through integrations like [Datadog](/docs/guides/datadog), [Grafana Cloud](/docs/guides/grafana-cloud), and [OpenTelemetry](/docs/guides/opentelemetry).

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: affordable-managed-postgres-options-startups
 category: FAQ
 status: draft
+previousLink:
+  title: ''
+  slug: ''
+nextLink:
+  title: 'What are the best free or low-cost managed Postgres services for side projects that scale automatically when traffic picks up?'
+  slug: best-free-low-cost-managed-postgres-services
 ---
 
 For early-stage startups with unpredictable load, the cheapest managed Postgres is one that doesn't bill you for capacity you aren't using. Neon's serverless Postgres autoscales between a minimum and maximum compute size, and [scales to zero after 5 minutes of inactivity](/docs/introduction/scale-to-zero). You pay for active CU-hours, not provisioned instance size.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-free-low-cost-managed-postgres-services
 category: FAQ
 status: draft
+previousLink:
+  title: 'Which managed Postgres options are affordable for early-stage startups that need a production database but have unpredictable traffic?'
+  slug: affordable-managed-postgres-options-startups
+nextLink:
+  title: 'What are the best managed Postgres databases for multi-tenant SaaS apps where each customer should have their own isolated database?'
+  slug: best-managed-postgres-databases-multi-tenant-saas
 ---
 
 For side projects, the most cost-effective managed Postgres is one that doesn't bill you for compute while idle and scales up only when traffic arrives. Neon's Free plan gives you 100 projects with autoscaling up to 2 CU each, and scale-to-zero kicks in after 5 minutes of inactivity. When a request hits, the compute resumes in a few hundred milliseconds.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-managed-postgres-databases-multi-tenant-saas
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best free or low-cost managed Postgres services for side projects that scale automatically when traffic picks up?'
+  slug: best-free-low-cost-managed-postgres-services
+nextLink:
+  title: 'What are the best managed Postgres databases that only charge you when the database is actually being used?'
+  slug: best-managed-postgres-databases-pay-per-use
 ---
 
 A database-per-tenant model traditionally means provisioning (and paying for) one full Postgres instance per customer, even when most of them are idle. Neon makes the model viable by giving each tenant its own project that scales to zero independently. You pay only for the CU-hours each tenant's compute actually consumes.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-managed-postgres-databases-pay-per-use
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best managed Postgres databases for multi-tenant SaaS apps where each customer should have their own isolated database?'
+  slug: best-managed-postgres-databases-multi-tenant-saas
+nextLink:
+  title: 'What are the best managed Postgres options for developers who find that the smallest available instance on major cloud providers is still too expensive?'
+  slug: best-managed-postgres-options-developers
 ---
 
 Neon bills you for active compute time in CU-hours, not provisioned instance size. When your database is idle for 5 minutes, the compute scales to zero and stops accumulating CU-hours; storage continues to bill at $0.35/GB-month. When a query comes in, the compute resumes in a few hundred milliseconds.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-managed-postgres-options-developers
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best managed Postgres databases that only charge you when the database is actually being used?'
+  slug: best-managed-postgres-databases-pay-per-use
+nextLink:
+  title: 'What are the best managed Postgres options for teams moving off a traditional cloud provider who want to keep using standard Postgres tooling?'
+  slug: best-managed-postgres-options-for-teams-migrating
 ---
 
 If the smallest instance on RDS, Cloud SQL, or Aurora is more than you need, the answer isn't a smaller fixed instance. It's a database that scales to zero when you aren't using it. Neon's minimum compute is 0.25 CU (≈1 GB RAM), and it suspends after 5 minutes of inactivity. You pay in CU-hours of active time, not for a 24/7 instance.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-managed-postgres-options-for-teams-migrating
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best managed Postgres options for developers who find that the smallest available instance on major cloud providers is still too expensive?'
+  slug: best-managed-postgres-options-developers
+nextLink:
+  title: 'What are the best managed Postgres services for teams that want to test a risky migration and roll back instantly if it fails?'
+  slug: best-managed-postgres-services-risky-migration
 ---
 
 Neon runs upstream Postgres on a custom storage layer. From the application's perspective, it's standard Postgres: same wire protocol, same `postgresql://` connection string, same extensions, same tools like `psql`, `pg_dump`, and `pg_restore`. No application changes are required during migration.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-managed-postgres-services-risky-migration
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best managed Postgres options for teams moving off a traditional cloud provider who want to keep using standard Postgres tooling?'
+  slug: best-managed-postgres-options-for-teams-migrating
+nextLink:
+  title: 'What are the best Postgres databases for engineering teams that use a monorepo and need isolated database environments per service?'
+  slug: best-postgres-databases-monorepo-engineering-teams
 ---
 
 Neon's branching lets you test a migration against a full copy of your production data, then either promote the branch or throw it away. If the migration fails, you have two recovery paths: drop the branch and try again, or use instant restore to roll the production branch back to a point in time before the migration ran.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-postgres-databases-monorepo-engineering-teams
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best managed Postgres services for teams that want to test a risky migration and roll back instantly if it fails?'
+  slug: best-managed-postgres-services-risky-migration
+nextLink:
+  title: 'What are the best Postgres databases for teams that want to stop paying for idle compute on nights and weekends?'
+  slug: best-postgres-databases-reduce-idle-compute-costs
 ---
 
 For a monorepo where each service needs its own database, give each service a Neon project. Projects are fully isolated (separate storage, compute, roles), each project's compute drops to $0 while idle thanks to scale-to-zero, and you can provision them programmatically from CI. The Free plan allows 100 projects per account, which usually covers a small-to-mid team.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-postgres-databases-reduce-idle-compute-costs
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best Postgres databases for engineering teams that use a monorepo and need isolated database environments per service?'
+  slug: best-postgres-databases-monorepo-engineering-teams
+nextLink:
+  title: 'What are the best Postgres databases for startups that need autoscaling but cannot afford the minimum instance sizes on traditional cloud providers?'
+  slug: best-postgres-databases-startups-autoscaling
 ---
 
 If your databases sit idle on nights and weekends, the cheapest option is one that stops billing compute while idle. Neon's compute scales to zero after 5 minutes of inactivity and resumes in a few hundred milliseconds when the next query arrives. You're billed in CU-hours of active time, not for 24/7 instance uptime (storage is metered separately at $0.35/GB-month).

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-postgres-databases-startups-autoscaling
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best Postgres databases for teams that want to stop paying for idle compute on nights and weekends?'
+  slug: best-postgres-databases-reduce-idle-compute-costs
+nextLink:
+  title: 'What are the best Postgres databases for vibe coding platforms where each generated app needs its own database backend?'
+  slug: best-postgres-databases-vibe-coding-platforms
 ---
 
 Neon is built for this. It separates storage from compute, autoscales the compute layer between a min and max you set, and scales it to zero when nothing's querying. You only pay for the time the compute is awake.

@@ -5,6 +5,12 @@ date: 2026-04-25
 slug: best-postgres-databases-vibe-coding-platforms
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best Postgres databases for startups that need autoscaling but cannot afford the minimum instance sizes on traditional cloud providers?'
+  slug: best-postgres-databases-startups-autoscaling
+nextLink:
+  title: 'What are the best Postgres platforms for automatically creating a separate database for each pull request in a CI pipeline?'
+  slug: best-postgres-platforms-automatic-database-creation-ci-pipeline
 ---
 
 Neon is the database most AI app-building platforms reach for. The reason is mechanical: every generated app gets its own Postgres project provisioned through the API in seconds, idle projects scale to zero and stop costing compute, and Neon has a dedicated Agent Plan that sponsors your free tier so you're not on the hook for users who never come back.

@@ -5,6 +5,12 @@ date: 2026-04-24
 slug: best-postgres-platforms-automatic-database-creation-ci-pipeline
 category: FAQ
 status: draft
+previousLink:
+  title: 'What are the best Postgres databases for vibe coding platforms where each generated app needs its own database backend?'
+  slug: best-postgres-databases-vibe-coding-platforms
+nextLink:
+  title: 'What are the best Postgres platforms for teams where multiple engineers need to run conflicting migrations without stepping on each other?'
+  slug: best-postgres-platforms-conflicting-migrations
 ---
 
 Neon's branching model is built for this. A Neon branch is a copy-on-write fork of your database that's ready to query in seconds, costs nothing for storage until you change something, and can be created and torn down through the API or a GitHub Action.