---
title: Neon Auth in Vercel projects, Postgres version updates, and more
---

## Neon Auth variables now set automatically in Vercel

For users of the [Neon Postgres Integration on Vercel](https://vercel.com/marketplace/neon), we've made it easier to get started with [Neon Auth](/docs/guides/neon-auth). When you connect a Vercel project to a Neon database, the integration now sets the environment variables required to use Neon Auth in your Next.js project:

- `NEXT_PUBLIC_STACK_PROJECT_ID`
- `NEXT_PUBLIC_STACK_PUBLISHABLE_CLIENT_KEY`
- `STACK_SECRET_SERVER_KEY`

These variables enable quick setup of Neon Auth, which syncs user profiles to your Neon database—making them queryable via the `neon_auth.users_sync` table. This simplifies authentication workflows in your app and removes the need to configure these values manually in Vercel.

To try Neon Auth, you can quickly deploy the [Next.js template for Neon Auth](https://github.com/neondatabase-labs/neon-auth-nextjs-template), which is preconfigured to use these variables.

For more details on how the Neon integration sets Vercel environment variables, see our [Vercel Native Integration guide](/docs/guides/vercel-native-integration).

## Postgres version updates

We updated supported Postgres versions to [14.18](https://www.postgresql.org/docs/release/14.18/), [15.13](https://www.postgresql.org/docs/release/15.13/), [16.9](https://www.postgresql.org/docs/release/16.9/), and [17.5](https://www.postgresql.org/docs/release/17.5/), respectively.

When a new minor version is available on Neon, it is applied the next time your compute restarts (for any reason). For more about how we handle Postgres version upgrades, refer to our [Postgres version support policy](/docs/postgresql/postgres-version-policy).

## Postgres version and region migrations using Import Data Assistant

Neon's **Import Data Assistant** can help you move your data when you need to update your Postgres version or change regions. Check out the [docs](/docs/import/import-data-assistant) for details on how to use it for these scenarios.

## Stream Arduino sensor data into Neon with NeonPostgresOverHTTP

During this week's product team hackathon, Peter Bendel (Postgres Performance Engineer) took top prize with a hardware project that streams Arduino sensor data directly into Neon. The project uses [NeonPostgresOverHTTP](https://github.com/neondatabase-labs/NeonPostgresOverHTTP/tree/v0.8.2) — an open-source library available in the [official Arduino Library Manager](https://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-installing-a-library/).

## New guides

We've published new guides to help you get the most out of Neon:

- [HONC Guide](/guides/honc) - Building serverless Task APIs with Hono, Drizzle ORM, Neon, and Cloudflare for edge-enabled data applications
- [Zero Guide](/guides/zero) - Integrating Zero by Rocicorp with Neon to build reactive, real-time applications with client-side cache and instant UI updates
- [File storage integration guides](/docs/guides/file-storage) for AWS S3, Azure Blob Storage, Cloudflare R2, and more - Learn how to store files in external services while tracking metadata in Neon
- [RedWoodSDK Guide](/docs/guides/redwoodsdk) - Connecting Neon to RedwoodSDK, a framework for building full-stack applications on Cloudflare

<details>

<summary>**Fixes & improvements**</summary>

- **Data API**
  - We upgraded the PostgREST engine that powers the [Neon Data API](/docs/data-api/get-started) to **version 13.0.0**. See the [PostgREST release notes](https://github.com/PostgREST/postgrest/releases) to learn more.
  - The management API spec for Data API endpoints ([create](https://api-docs.neon.tech/reference/createprojectbranchdataapi), [delete](https://api-docs.neon.tech/reference/deleteprojectbranchdataapi), [get](https://api-docs.neon.tech/reference/getprojectbranchdataapi)) is now available.

    > The [Data API](/docs/data-api/get-started) is out in Early Access. [Sign up](/docs/introduction/early-access) to try it out.

- **Neon Console**
  - Copy improvements may not typically warrant a changelog entry, but this one addresses a common point of confusion: the default compute settings UI now makes it clear that changes _only_ apply to new computes you create, not existing ones.

    ![compute default settings](/docs/changelog/compute_settings.png)

- **Neon RLS**
  - Fixed an issue that prevented permissions from being granted to Neon RLS roles on read replicas.

</details>