You don't need Vercel Pro. You need your stack to sleep.

TL;DR for vibe coders: Shipped an app with Cursor, Claude Code, or v0 and got a scary Vercel or Neon bill? You probably don't need a bigger plan. You need a few fixes. Not technical? Copy the , )

The headline feature on both is scale to zero. When nothing is happening, the database suspends and your functions aren't running, so you pay close to nothing. Neon's compute auto-suspends after 5 minutes of inactivity by default and wakes again in a few hundred milliseconds. (.

One honest caveat. "Truly zero" has a small floor, because Neon's control plane checks availability periodically, so don't expect a perfectly flat line. What you're hunting for is long idle stretches, and those were completely missing here.

Lever 1: stop paying to build

This one isn't about sleep, it's just the easiest money on the table. By default Vercel runs a metered cloud build on every push and every PR preview. Build it yourself and upload the result, and Vercel skips the build entirely:

CODE Kopieren

vercel pull --yes --environment=production   # get project settings + prod env

vercel build --prod                          # build on YOUR machine into .vercel/output

vercel deploy --prebuilt --prod              # upload the output; Vercel does not rebuild

Prebuilt-only costs you preview URLs, push-to-deploy, and Git rollback. Run the same step from GitHub Actions instead and you keep all of that with no billed build minutes (see )

CODE Kopieren

// lets the database sleep

import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL, { fullResults: true });

const { rows } = await sql.query("SELECT now()");

Keep a real Pool only in CLI scripts, migrations, and long-running servers. (If you genuinely need a pool inside functions, Vercel's Fluid Compute plus and , )

Match revalidate to the data. This data refreshed daily and the source only changed quarterly, so hourly revalidation was ~24x more often than anything actually changed. Daily was plenty.

After this, a bot crawl serves from the CDN instead of waking the database, and the compute can finally suspend between real events.

The result

The proof was in the real-time endpoint state and the forward active_time delta. Long idle stretches appeared where there had been none, the unchanged control project stayed put, and the apps did the same work while spending most of their lives asleep. No plan change required. You can run the same check on your own stack with the is built the way it is. If you're not deep in serverless billing, maybe you vibe-coded the app and just want the bill to stop, you don't have to understand any of the above. Copy the rules file into your editor and tell your agent to apply it. Cost knowledge belongs in the agent's context, not just in a senior engineer's head.

The checklist

Copy and paste this into your next serverless project:

• Driver: HTTP neon() in request handlers; Pool only in CLI and migrations (or Fluid Compute with attachDatabasePool()).


• No DB-polling crons more frequent than the suspend window; event-driven work via after().


• No force-dynamic on DB-backed public routes; ISR with revalidate matched to the data's cadence; empty generateStaticParams() for [slug] routes.


• No DB write on every bot or analytics hit; log to stdout or sample.


• Build prebuilt with vercel deploy --prebuilt to skip remote build minutes.


• Measure with endpoint current_state plus active_time delta and the Vercel usage dashboard, not Google Analytics.


• Drop the . If it helped, a star helps other people find it.
  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen