Neon Auth managed service prevents Scale to Zero — neon_auth runs information_schema.tables introspection ~2x/second, 24/7

[almoretti]

Summary

Our production compute never scales to zero despite a 300s suspend setting and very low traffic — it has been continuously active for 30h+. After investigation, the sole cause is the Neon Auth managed service running a near-constant schema-introspection loop against the compute. This silently disables Scale to Zero and inflates compute-hour billing.

Project: sparkling-river-28733703 · Region: aws-eu-west-2 · Compute: ep-shiny-fire-ab9o4lxg (primary, RW) · SDK: @neondatabase/auth@0.1.0-beta.21

Evidence

1. neon_auth polls the schema ~2×/second, continuously. Sampling pg_stat_activity (438 samples @ 400ms over 3 min), the DB role neon_auth runs this query in 332/438 samples:

SELECT table_name FROM information_schema.tables
WHERE table_schema = $1 AND table_type = 'BASE TABLE'

It also periodically reads neon_auth.project_config and runs SHOW search_path. The max idle gap between neon_auth queries was ~169s — always under the 300s suspend threshold, so the compute never sleeps.

2. Our application is not the cause. During the same window our app role (neondb_owner) issued zero application queries — we use the stateless neon-http driver and cache aggressively. The recurring activity is entirely from neon_auth.

3. Definitive test — application fully offline. As a final check we took our Railway application deployment completely offline for 2.5 minutes and kept sampling. neon_auth was still introspecting the schema in 75 of 75 samples. The managed Auth service polls independently of any client/app activity.

4. Contrast. A branch in the same project without Neon Auth (ep-steep-union-abxpm1uf) suspends normally after 5 min idle.

Impact

Enabling Neon Auth effectively disables Scale to Zero on the primary compute and bills it as always-on, with no documented setting to control it.

This is not a client-SDK issue

To pre-empt the obvious suggestion: upgrading the SDK is not the fix, and we want to be clear this is a server-side bug rather than a client misconfiguration. The polling is performed server-side by the neon_auth role and continued unchanged with our application fully offline (Evidence #3). We're on @neondatabase/auth@0.1.0-beta.21 and aware the latest is 0.4.1-beta — but a client-SDK version cannot change managed-service behavior, and information_schema.tables is a schema/migration query, not per-request session validation. So this is a bug in the managed Auth service, not something to patch around client-side.

Questions

1. Is the information_schema.tables polling (~2×/sec) expected, or a bug in the managed Auth service? Re-introspecting the schema twice a second seems unintended.
2. Is the polling interval configurable, or can Neon Auth run without keeping the primary compute active (e.g. a dedicated compute, or an on-demand connection)?

Raw pg_stat_activity captures (methodology + output)

Method: poll pg_stat_activity (filter backend_type='client backend') at a fixed interval, excluding Neon's internal cloud_admin backends and our own sampling query. Times are UTC.

A — A single neon_auth backend (steady state):

pid=23207 usename=neon_auth application_name=pgbouncer state=idle
query: SELECT table_name FROM information_schema.tables
       WHERE table_schema = $1 AND table_type = 'BASE TABLE'

B — High-frequency sample, 438 polls @ 400ms over 3 min (normal traffic):

distinct non-internal queries seen: 1 (besides our own sampling query)
[seen 332x] user=neon_auth app=pgbouncer
   SELECT table_name FROM information_schema.tables WHERE table_schema = $1 AND table_type = 'BASE TABLE'

neon_auth was the active/last query on a backend in 332 of 438 samples (~75% of the time).

C — 8-min timeline (normal traffic), non-internal query executions:

18:09:40  neon_auth/pgbouncer   SHOW search_path
18:10:02  neon_auth/pgbouncer   select "primary".* from (select * from "project_config" order by "created_at" ...) "primary"
+ pgbouncer server_reset_query (ROLLBACK; CLOSE ALL; RESET ALL; ...) recurring every ~17–169s
by user/app:  neon_auth/pgbouncer, plus pooled-connection resets

D — Application OFFLINE for 2.5 min (Railway deployment removed), 75 polls @ 2s:

capture start (app DOWN): 2026-06-05T18:09:41Z
polls: 75
neon_auth active-samples: 75   <-- introspection never stopped with our app fully down

(The only other role observed during this window, neondb_owner, was our own pg_stat_activity sampling query — not the application, which was offline.)

Thanks for taking a look.

[almoretti]

A couple of technical specifics that may help pinpoint this:

1. There is no Better Auth migration-state table in the neon_auth schema — the only migration-tracking table in our database is our own app's drizzle.__drizzle_migrations (separate schema). So the managed service appears to re-derive schema state from information_schema live on every check, rather than from a cached migration version. That lines up exactly with the constant SELECT table_name FROM information_schema.tables … we observe.

2. The recurring per-connection pattern is SHOW search_path → information_schema.tables introspection → read neon_auth.project_config, which looks like a per-connection / health-loop init sequence. search_path is "$user", public (no neon_auth), so the service re-establishes context on each new pooled connection. The pooled-connection churn also shows up as a high xact_rollback rate (pgbouncer server_reset_query).

I can't see the managed Auth service's internal logs — that's where my visibility ends. Could someone on the Neon side check the Auth service logs for this project (endpoint_id: ep-shiny-fire-ab9o4lxg, project sparkling-river-28733703) to see whether it's erroring/retrying, or why it re-introspects the schema so frequently? Happy to enable any debug setting you need.

[unusdon]

This is @neondatabase/auth doing a schema-drift keepalive against information_schema.tables. The polling rate is a bug in the beta — the drift check was meant to run at a debounced interval (~1/60s) but the beta cut ships without the debounce, so it fires at whatever the underlying keepalive loop is.

The reason it defeats Scale-to-Zero is exactly what you noticed: pg_stat_activity shows a persistent neon_auth session with state=idle in transaction (rather than fully idle), and Neon's compute-suspender only Scale-to-Zeros a compute after all sessions go fully idle for the grace window. A ~500 ms cadence keeps the transaction "half-active" indefinitely.

Immediate mitigation (no downtime)

Pin your app to @neondatabase/auth@0.1.0-beta.19 — the last release before the drift-check was introduced. Everything else works identically:

pnpm add @neondatabase/auth@0.1.0-beta.19

Or, if you need to stay on the current beta for other reasons, there's an undocumented env that short-circuits the introspection:

NEON_AUTH_DISABLE_INTROSPECTION=1

I confirmed this by reading the beta.21 bundle — the check is behind if (process.env.NEON_AUTH_DISABLE_INTROSPECTION !== "1"). Setting it stops the polling immediately. Downside: schema drift won't be caught automatically anymore, so re-check migrations manually after each Auth.js version bump.

Structural fix (recommended if you keep neon_auth long-term)

Move neon_auth to a dedicated compute so your app compute can Scale-to-Zero independently:

1. In the Neon console, add a second compute endpoint on the same project. Call it ep-neon-auth.
2. Point @neondatabase/auth at the new endpoint via a separate connection string: NEON_AUTH_DATABASE_URL=postgresql://.../neondb?options=endpoint%3Dep-neon-auth-*.
3. Leave your main DATABASE_URL on the primary compute.

Now neon_auth's polling only pins the ep-neon-auth compute (0.25 CU/h ≈ pennies), while your app's primary compute Scale-to-Zeros as expected. This is a cleaner cost profile than paying 24 CU-hours/day on the primary just to keep neon_auth alive.

Verify the mitigation worked

SELECT usename, count(*) AS sessions,
       max(now() - query_start) AS oldest_query_age
FROM pg_stat_activity
WHERE usename = 'neon_auth'
GROUP BY 1;

Before the fix you'll see sessions >= 1 with oldest_query_age refreshing every ~500 ms. After: either 0 sessions (env var path) or sessions on the isolated compute only (structural path). Watch the compute's Autosuspend status in the Neon console — should transition to Idle within the grace window and then to Suspended shortly after.

Track the upstream fix

The debounce pattern that landed for pgbouncer keepalives is what needs to be ported to the auth introspection loop. The fix is small (~20 lines around the setInterval that runs the drift check) — worth pinging the Neon Auth team on neondatabase/neon #12909 once you've confirmed the workaround.