DEV Community: DevOps Daily

SPF, DKIM, DMARC: the 15-minute setup that actually passes

DevOps Daily — Wed, 22 Jul 2026 10:23:20 +0000

Every guide to email authentication starts with a history lesson. Skip it. You are here because your emails land in spam, or a client asked "is DMARC set up?", or you saw dmarc=fail in a bounced message. Here is the 15-minute version: the exact records, why each one exists in one sentence, and how to verify you got it right.

The one-sentence versions

SPF lists which servers may send mail claiming to be from your domain.
DKIM cryptographically signs each message so receivers can verify it was not altered and really came from you.
DMARC tells receivers what to do when SPF or DKIM fail, and sends you reports about it.

SPF and DKIM are the mechanisms. DMARC is the policy on top. You need all three.

SPF: one TXT record

At your domain root (or the subdomain you send from), add a TXT record:

v=spf1 include:_spf.yourprovider.com ~all

Replace the include with whatever your email provider documents. Sending through Amazon SES it is include:amazonses.com; Google Workspace is include:_spf.google.com. If you send through several providers, chain the includes in a single record:

v=spf1 include:amazonses.com include:_spf.google.com ~all

Mistake #1: two SPF records. SPF allows exactly one TXT record starting with v=spf1 per domain. Two records means SPF returns a permanent error, which is worse than no record at all. Merge them.

Also know the 10-DNS-lookup limit: every include costs lookups, and past 10 the check fails. If you have collected includes from years of tools, prune them.

Verify it with dig:

dig +short TXT yourdomain.com | grep spf1

or use a checker that also counts your lookups, like this free SPF checker.

DKIM: the CNAMEs your provider gives you

You do not write DKIM records by hand. Your provider generates a key pair, keeps the private key, and gives you DNS records (usually 1 to 3 CNAMEs) that publish the public key. They look like:

abc123._domainkey.yourdomain.com  CNAME  abc123.dkim.provider.com

Add them exactly as given and wait for verification. That is it.

Mistake #2: proxying the DKIM CNAMEs. If your DNS is behind Cloudflare, those records must be DNS only (grey cloud). Proxied CNAMEs resolve to Cloudflare IPs and DKIM verification never completes. This one costs people days.

Verify with the selector your provider used:

dig +short TXT abc123._domainkey.yourdomain.com

You should see a v=DKIM1; k=rsa; p=... blob. A DKIM checker does the same with the parsing done for you.

DMARC: start monitoring, then enforce

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

p=none means "change nothing, just send me aggregate reports about who is sending as my domain." Run in this mode for a couple of weeks and read the reports; you will usually discover a forgotten tool sending as your domain.

Then enforce:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

and eventually p=reject. Enforcement is what actually stops spoofing, and since 2024 Gmail and Yahoo require a DMARC record for bulk senders at all.

Mistake #3: jumping straight to p=reject. If some legitimate system sends unaligned mail (a CRM, a billing tool, an old cron job), p=reject silently kills those messages. Monitor first, enforce second.

Verify:

dig +short TXT _dmarc.yourdomain.com

or decode the policy in plain English with a DMARC analyzer.

The 15-minute checklist

One SPF record, correct include, ~all at the end. Check the lookup count.
Add the provider's DKIM CNAMEs, unproxied. Confirm the selector resolves.
_dmarc record at p=none with a rua address. Calendar reminder for two weeks: read reports, move to quarantine, then reject.
Send a test email to a Gmail account, open "Show original", and confirm all three lines say PASS.

Step 4 is the ground truth. Gmail's "Show original" view shows spf=pass dkim=pass dmarc=pass right at the top, and it is checking the real thing rather than just the DNS.

Once these pass, deliverability problems stop being an authentication problem and start being a reputation problem. That is a different article, but you cannot get there without this one.

While speaking of emails, if you want to learn how SMTP works under the hood, watch a message move from application code to an SMTP relay, through TLS and AUTH, across DNS and recipient MX checks, and finally into a mailbox check out this simulator: SMTP Flow Simulator

I gave my AI agent the ability to send email

DevOps Daily — Mon, 20 Jul 2026 19:43:43 +0000

Last month I wired Claude up to my email infrastructure. Not "Claude writes an email draft and I paste it somewhere" but the agent checks my domain status, sends the email, and reads back the delivery events, all from the chat.

The glue that makes this possible is MCP (Model Context Protocol), and the whole setup takes about five minutes. Here is exactly how to do it, plus what surprised me once agents could actually touch production infrastructure.

What MCP actually is

MCP is a small JSON-RPC protocol that lets an AI client (Claude, Cursor, Windsurf, your own agent) call tools exposed by a server. The server describes its tools with JSON schemas, the model picks a tool and fills in the arguments, and the client executes the call.

The important design decision is where the server runs. A lot of MCP servers are local stdio processes you install per machine. For anything talking to a hosted API, a hosted MCP server is the better shape: nothing to install, your API key is the auth, and every client that speaks HTTP can use it.

I use SMTPfast for transactional email, which ships a hosted MCP endpoint at https://smtpfa.st/api/mcp. That is what I will use in the examples, but the pattern applies to any hosted MCP server.

Step 1: Connect Claude Code

One command:

claude mcp add --transport http smtpfast https://smtpfa.st/api/mcp \
  --header "Authorization: Bearer sf_your_api_key"

For Cursor, it is a snippet in .cursor/mcp.json:

{
  "mcpServers": {
    "smtpfast": {
      "url": "https://smtpfa.st/api/mcp",
      "headers": { "Authorization": "Bearer sf_your_api_key" }
    }
  }
}

That is the entire installation. No npm package, no local process, no version drift between machines.

Step 2: See what the agent can do

MCP servers self-describe. You can poke one with curl to see the tool list:

curl -sS https://smtpfa.st/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sf_your_api_key" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The SMTPfast server exposes eight tools: send_email, list_emails, get_email, list_domains, verify_domain, list_suppressions, get_analytics, and list_contacts. The model reads those schemas and figures out the rest on its own.

Step 3: Just ask

With the server connected, I can type things like this into Claude:

"Check if my domain is verified, then send a test email from hello@mydomain.com to my personal address and tell me when it is delivered."

Behind the scenes the agent calls list_domains, sees the DKIM status, calls send_email, waits, then calls get_email to read the delivery events. I watch each tool call go by and approve it. No SDK, no glue code, no copy-pasting message IDs.

The debugging workflow is where this gets genuinely useful:

"Why did the email to jane@example.com bounce yesterday?"

The agent pulls the email, reads the bounce event with the SMTP diagnostic code, checks whether the address landed on the suppression list, and explains it in plain language. That used to be five minutes of clicking through a dashboard.

What surprised me

1. The approval step matters more than I expected. Most MCP clients show you each tool call before it runs. For read tools that feels like friction. For send_email it is exactly right. I would not connect a send-capable tool to an agent that runs unattended without scoping the key first.

2. Agents are great at chaining, bad at restraint. Ask a vague question and the agent will happily call four tools when one would do. Tight tool descriptions in the server matter as much as good prompts.

3. The server is the easy part. If your product already has a REST API, an MCP server is mostly a translation layer: tool schema in, API call out. The hard work (auth, rate limits, validation) already exists in the API. That is also why I prefer hosted MCP over stdio: it reuses everything the API already enforces, including that a compromised key can be revoked in one place.

Try it

If you want to reproduce this end to end: grab a free SMTPfast account (3,000 emails/month, no card), verify a domain, create an API key, and run the claude mcp add command above. The MCP docs cover the tool schemas and a few example prompts.

And if you are building a dev tool yourself: ship the hosted MCP endpoint. It is a weekend of work and it makes your product usable by every AI agent your customers already run.

I Gave an AI Agent a Database, Compute, Storage, and Models From One CLI

DevOps Daily — Wed, 15 Jul 2026 15:21:45 +0000

A working AI agent has an unglamorous shopping list. It needs a database to remember things, somewhere to run that can stream tokens without timing out, object storage for whatever it produces, and access to a model. Assembled the usual way, that is four separate signups: a Postgres host, a compute platform, an S3 bucket, and an OpenAI or Anthropic account, each with its own credential to provision, inject, and rotate per environment.

Neon's June 2026 platform preview collapses that list. The pitch is that the database, the compute, the storage, and the model gateway all come from one account and branch together. I wanted to know if that was real or a slide, so I built the canonical example end to end: an image-generating agent that takes a prompt, calls a model, stores the result, and indexes it in Postgres. This is the build log, with the real commands and output, and the parts where the preview still shows.

(Companion repo: The-DevOps-Daily/neon-ai-agent. Everything below ran against a fresh project created while writing.)

One command to scaffold the whole stack

Neon ships starter templates through its CLI. The image agent is one of them:

neonctl bootstrap ./ai-agent --template ai-sdk

That scaffolds 26 files: a Hono function, a Drizzle schema, a neon.ts config, and (a nice touch) a .agents/skills/ directory with skill docs for the AI assistant you are probably using to edit the project. Neon bundles agent instructions for its own products, which tells you who this template is aimed at.

The file that matters is neon.ts. It is the entire backend declared in one object:

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    aiGateway: true,
    buckets: {
      images: {},
    },
    functions: {
      imagegen: {
        name: 'AI SDK image agent',
        source: 'src/index.ts',
      },
    },
  },
});

Three lines of intent: turn on the AI gateway, give me a bucket called images, and deploy src/index.ts as a function. No connection strings, no bucket ARNs, no model API keys. Those get filled in later, automatically.

Linking creates the project, deploying creates everything else

neon link creates and attaches a Neon project. The new platform features are private preview, so there are two constraints worth stating up front: everything is in AWS us-east-2, and it only works on projects created inside the preview. Your existing Neon databases do not grow these features in place.

Then neon deploy reads neon.ts and provisions the declared services. Here is the whole sequence, link through deploy:

That last line is the actual product. Eleven environment variables (the DATABASE_URL, the S3 access key/secret/endpoint, and the AI gateway token and base URL) all written for me, all scoped to this branch. The four credentials I would normally collect from four dashboards arrived from one deploy.

The model call: one credential, any provider

The AI Gateway is OpenAI-compatible. Your existing SDK works by changing only the base URL, so the same chat completion against the cheapest catalog model looks like this in whatever you already use:

curl:

curl "$NEON_AI_GATEWAY_BASE_URL/ai-gateway/mlflow/v1/chat/completions" \
  -H "Authorization: Bearer $NEON_AI_GATEWAY_TOKEN" \
  -d '{"model":"gpt-5-nano","messages":[
        {"role":"user","content":"What is Neon branching?"}]}'

Python:

from openai import OpenAI

client = OpenAI(base_url=GATEWAY_URL, api_key=GATEWAY_TOKEN)
client.chat.completions.create(
    model="gpt-5-nano",
    messages=[{"role": "user", "content": "What is Neon branching?"}],
)

Node:

import OpenAI from 'openai';

const client = new OpenAI({ baseURL: GATEWAY_URL, apiKey: GATEWAY_TOKEN });
await client.chat.completions.create({
  model: 'gpt-5-nano',
  messages: [{ role: 'user', content: 'What is Neon branching?' }],
});

Hitting it once returns exactly what you would expect from the model:

{
  "model": "gpt-5-nano-2025-08-07",
  "choices": [{ "message": { "role": "assistant",
    "content": "Neon Postgres branching creates lightweight, independent
      clones of a running database that can be developed in isolation..." }}]
}

The same token reaches around 25 models across Anthropic, OpenAI, Google, and a few open-source providers. You move between them by changing one model string. There is no separate OpenAI or Anthropic account in this project. The published prices look like each provider's own list rate, so the gateway reads as pass-through with the convenience of a single credential:

The point is not the specific numbers, it is that "use a cheap model in CI and a frontier model in prod" becomes a config value rather than a second vendor integration.

Storage that the function can reach with the normal S3 SDK

The images bucket is plain S3 as far as your code is concerned. The injected AWS_* variables point the standard AWS SDK at a branch-scoped endpoint, so this just works inside the function with no custom client:

const s3 = new S3Client({ forcePathStyle: true });
await s3.send(new PutObjectCommand({
  Bucket: 'images', Key: key, Body: jpeg, ContentType: 'image/jpeg',
}));
const url = await getSignedUrl(s3, new GetObjectCommand({ Bucket: 'images', Key: key }));

I confirmed it directly: a PutObject then GetObject round-tripped, and the presigned URL came back on a host scoped to the branch (br-green-star-….storage.c-3.us-east-2.aws.neon.tech). That branch scoping is the part you cannot get by bolting an external S3 bucket onto a database: open a branch and its files fork with it, so a preview environment never writes into production's objects.

Putting it together: the agent runs

The function is a small handler. It streams a model response, and when the model calls its image-generation tool, it uploads the JPEG to the bucket, inserts a row in Postgres, and returns a presigned URL. Calling the deployed agent:

curl -X POST "$IMAGEGEN_URL" -H 'content-type: application/json' \
  -d '{"messages":[{"role":"user",
       "content":"Draw a small minimalist server rack icon, flat style"}]}'

The response streams back as the agent narrates and draws, and afterward the side effects are all there. The object is in the bucket, and the row is in Postgres pointing at it:

 id |              prompt               |             bucket_key              | bytes
----+-----------------------------------+-------------------------------------+-------
  2 | Draw a small minimalist server... | generated/ed49b102-…-f8c46e2f8c16.jpg | 47372
  1 | Draw a small minimalist server... | generated/9125d5b4-…-63b54a892695.jpg | 47372

From an empty directory to a deployed agent that generates an image, stores it, and indexes it in Postgres took a few minutes and exactly one credential. The model call, the file write, and the database insert were all wired by the platform, not by me.

Where it still shows the preview

The build was smooth, but it is private preview and a few seams are worth knowing before you plan around it.

One region, new projects only. Everything is in AWS us-east-2 and only works on projects created inside the preview. You cannot bolt these features onto an existing production database today.

Functions are request/response, not a job runner. Great for the agent's synchronous loop and streaming; background work (queues, retries, schedules) still belongs to something like Inngest or QStash.
Two gateway dialects, and it matters. The OPENAI_BASE_URL Neon injects points at the OpenAI Responses API route. A plain chat-completions call needs the mlflow dialect route instead. I hit a 404 until I switched routes. The SKILL docs the template ships actually explain this, which is the kind of detail that saves you ten minutes if you read it first.
Billing is half-public. Per-model token prices are listed, but whether there is a markup or preview credits on top is not spelled out. Fine for a demo, a question to ask before a budget.
The convenience is also coupling. One config file declaring your functions, buckets, and gateway is, by design, Neon-shaped. The S3-compatible API and standard SDKs keep the exit ramps wide, but this is a bet on one vendor for four things you used to buy separately.

So is it real?

Yes, with an asterisk for "preview." The genuinely useful part is not any single feature, it is that the four pieces an agent needs arrive together, branch together, and authenticate with one credential. If you have ever spent the first afternoon of an AI side project wiring a database to a compute host to an S3 bucket to a model provider, collapsing that into one neon.ts and one deploy is a real reduction in moving parts.

Whether you should build on it today depends on your appetite for a private preview and for vendor consolidation. But as a statement of direction, an agent stack from one CLI is a clear one. We dig into the strategy behind it in Neon is becoming a backend platform, not just Postgres, and we benchmark Neon's database side in the Neon vs Supabase series. As these features leave preview, we will keep testing them the same way: real projects, real output, and the demo code published so you can run it yourself.

The full project is on GitHub. Clone it, point neonctl at a new us-east-2 project, and deploy:

https://github.com/The-DevOps-Daily/neon-ai-agent

Realtime Without a WebSocket Service

DevOps Daily — Wed, 15 Jul 2026 15:09:58 +0000

The moment a feature needs to update live, a live counter, a presence indicator, a "new message" badge, an activity feed, the reflex is to reach for a websocket service. Pusher, Ably, a Socket.IO server, a stateful Node process parked next to your stateless app. That is one more thing to deploy, scale, secure, and pay for, and it exists mostly to move small events from one place to a bunch of connected browsers.

If your data already lives in Postgres, you already have a message bus for that. Postgres ships with LISTEN and NOTIFY, a lightweight publish/subscribe system built into the database. Pair it with server-sent events from a serverless function and you can fan realtime updates out to every connected client without standing up any realtime infrastructure at all. In this post I build exactly that on a Neon Function, explain the one part that is subtle on serverless, and prove it works with two live subscribers. The repo is at the end.

TL;DR

Postgres LISTEN/NOTIFY is a built-in pub/sub. NOTIFY channel, 'payload' delivers to every connection that has run LISTEN channel.
A serverless function holds each browser's SSE connection open and keeps one Postgres LISTEN connection. On a write, the app calls pg_notify, and every isolate pushes the event to its SSE clients.
The subtle part on serverless: the runtime runs several isolates, each with its own in-memory set of clients. LISTEN/NOTIFY is what fans an event across all of them; an in-process broadcast alone would only reach one isolate's clients.
One real gotcha: LISTEN needs a session, so it must use a direct (unpooled) connection, not the transaction pooler.
It is fan-out for small live events, not a durable queue. For guaranteed delivery or bidirectional low-latency you still want a real broker or websockets.

Prerequisites

A Neon project on the platform preview (Functions, us-east-2)
The Neon CLI (npm i -g neon, then neon login)
Familiarity with Postgres and with SSE / EventSource on the client

The two pieces

Postgres LISTEN/NOTIFY is a pub/sub channel inside the database. A connection subscribes with LISTEN counter_updates, and any connection (from anywhere) that runs NOTIFY counter_updates, '42' causes Postgres to deliver that payload to every subscriber. No extra service, no broker to run; it is a feature of the database you already have.

Server-sent events (SSE) are the other half. SSE is a long-lived HTTP response that streams data: frames to the browser, consumed with the built-in EventSource API. It is one-directional (server to client), which is exactly the shape of most realtime UI: the server has news, the browser wants it. And because it is just an HTTP response, a serverless function can serve it.

Put them together: the function streams SSE to browsers and relays anything it hears on a Postgres channel.

The part that is subtle on serverless

Here is the trap. A function under load does not run as one process; the runtime spins up several isolates in parallel. Each isolate has its own memory, so each keeps its own set of open SSE connections. If you only broadcast in-process, a client connected to isolate A never sees an event triggered through isolate B.

LISTEN/NOTIFY is what closes that gap. Every isolate opens its own LISTEN connection to Postgres. When any code anywhere calls NOTIFY, Postgres delivers it to all of those connections, so every isolate gets the event and pushes it to its own clients. Postgres is the shared fan-out point that the isolates do not otherwise have.

// One dedicated LISTEN connection per isolate. LISTEN needs a real session,
// so use the DIRECT (unpooled) URL, not the transaction pooler.
const listener = new Client({ connectionString: env.postgres.databaseUrlUnpooled });
await listener.connect();
await listener.query('LISTEN counter_updates');

// SSE connections held open by THIS isolate.
const clients = new Set<ReadableStreamDefaultController<Uint8Array>>();

listener.on('notification', (msg) => {
  const frame = new TextEncoder().encode(`data: ${msg.payload}\n\n`);
  for (const c of clients) c.enqueue(frame); // push to this isolate's browsers
});

The write path is a normal query plus a NOTIFY:

app.post('/increment', async (c) => {
  const [row] = await db
    .insert(counters)
    .values({ id: 1, value: 1 })
    .onConflictDoUpdate({ target: counters.id, set: { value: sql`${counters.value} + 1` } })
    .returning({ value: counters.value });
  // Fan the new value out to every isolate, and thus every browser.
  await pool.query('SELECT pg_notify($1, $2)', ['counter_updates', String(row.value)]);
  return c.json({ value: row.value });
});

And the SSE endpoint just registers the browser and streams:

app.get('/events', async (c) => {
  const stream = new ReadableStream<Uint8Array>({
    start(controller) {
      clients.add(controller);
      // send the current value immediately so a new tab is correct on load
      readCount().then((v) => controller.enqueue(encode(`data: ${v}\n\n`)));
    },
    cancel() {
      /* remove this controller from clients */
    },
  });
  return new Response(stream, {
    headers: { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache' },
  });
});

LISTEN holds a session-level subscription, which the transaction pooler (PgBouncer in transaction mode) does not support. Use the direct, unpooled connection string for the listener (Neon injects it as DATABASE_URL_UNPOOLED). Keep using the pooled URL for your normal queries. Getting this wrong is the usual reason "notifications never arrive."

Proving it works

I deployed the counter as a Neon Function and connected two independent SSE subscribers, then fired three increments. Every subscriber should see its starting value on connect and then each new value as it happens. Here is the actual run:

Both streams saw every value. Neither subscriber talked to the other, and there is no websocket server anywhere in this picture; the events traveled browser → function → Postgres NOTIFY → every function isolate → every browser.

WebSocket service vs LISTEN/NOTIFY + SSE

	Dedicated websocket service	LISTEN/NOTIFY + SSE on a function
Extra infrastructure	A service to run, scale, secure	None; uses Postgres + the function
Direction	Bidirectional	Server to client (SSE)
Fan-out bus	The service	Postgres `NOTIFY`
Delivery	Often buffered / retried	Best-effort; dropped if no listener
Best for	Chat, cursors, games, huge fan-out	Live counters, feeds, notifications, presence

Where this stops being enough

This pattern is a genuine "delete a service" win for a large class of realtime features, but be honest about its edges:

It is not a durable queue. NOTIFY is fire-and-forget. If nobody is listening at that instant, the message is gone. That is fine for a live UI that re-reads state on reconnect; it is not fine for guaranteed delivery or work queues.
Payloads are small. Postgres caps a NOTIFY payload at 8000 bytes. Send an id or a small value and let clients fetch details, rather than shipping large blobs through the channel.
SSE is one-way. For low-latency bidirectional traffic (multiplayer, live cursors, collaborative editing) a websocket is still the right tool.
At very high scale a dedicated broker earns its keep. This shines at the small-to-medium fan-out that most apps actually need, without the standing infrastructure.

The repo

The full counter, backend function plus a small web client, is here:

https://github.com/The-DevOps-Daily/neon-realtime-demo

Wrapping up

Realtime does not always mean a websocket service. For the common cases, a live number, a badge, a feed, an activity stream, Postgres LISTEN/NOTIFY is a pub/sub you already run, and SSE from a serverless function is enough to get those events to the browser. On Neon the function lives on the branch next to Postgres, so the listener connection is a local hop and the whole realtime path is one deploy, no separate service to operate. Reach for a real broker or websockets when you need durability or two-way low latency; reach for this when you just want the UI to update and would rather not run another box to make it happen.

Preview Environments That Include the Backend, Not Just the Frontend

DevOps Daily — Wed, 15 Jul 2026 15:00:57 +0000

Open a pull request and your frontend host hands you a preview URL. Vercel, Netlify, Cloudflare Pages all do it: every PR gets its own isolated build you can click through before merging. It is one of the genuinely great DevOps conveniences of the last decade.

Then you look at what that preview talks to. The API and the database behind it are almost always a single shared staging environment. Every open PR hits the same backend, runs migrations against the same schema, and reads and writes the same rows. So the preview is only half a preview. The frontend is isolated; the thing it depends on is a free-for-all.

Neon changes what a "branch" contains. A branch is not just a copy of your schema, it is a copy-on-write copy of the data too, and with Neon Functions the compute deploys onto that branch as well. So a branch is the database, its data, and the backend, forked together, each with its own URL. That makes a real per-PR backend cheap enough to create and throw away on every pull request. In this post I show the workflow and prove the isolation with a live function, then sketch how to wire it into CI.

TL;DR

Frontend previews are isolated per PR. The backend they call usually is not, so previews share one staging database and its migrations and data.
A Neon branch copies the schema and the data (copy-on-write), and Neon Functions deploy onto the branch, so each branch is a full isolated backend with its own function URL.
I tested it: branched a live todos API, the branch came up with a copy of main's rows, a write to the branch left main untouched, and the branch had its own URL.
In CI this is: on PR open, create a branch and deploy the function; hand the frontend preview that branch's URL; on PR close, delete the branch and everything goes with it.
Because branches are copy-on-write and functions scale to zero, a preview backend costs almost nothing while it sits idle.

Prerequisites

A Neon project on the platform preview (Functions, us-east-2) with a deployed function
The Neon CLI (npm i -g neon, then neon login)
A CI system that can run CLI commands on pull-request events (the example uses GitHub Actions)

Why shared staging quietly hurts

A shared staging backend fails in ways that are easy to miss until they bite:

Migrations collide. Two PRs each add a column, or one renames a table the other still reads. Whoever runs their migration second gets a broken staging environment, and now both previews are wrong.
Data bleeds between PRs. One PR's test run creates records another PR's preview then displays. Bugs appear and vanish depending on who ran what, and nobody can reproduce them.
The preview is not like production. To avoid touching real data, staging often runs a thin set of seed fixtures, so the preview never sees the shape or volume of real data and "works in preview" does not mean "works in prod."
Resetting is scary. Because everyone shares it, nobody wants to be the one who wipes staging, so bad data accumulates for months.

None of this is a tooling failure on the frontend side. It is that the backend was never actually part of the preview.

What a Neon branch gives you

A Neon branch is a copy-on-write fork of the database at a point in time. It starts with the parent's schema and data instantly, without physically copying the bytes, and it diverges only as you write to it. Neon Functions extend that: when you deploy, the function is applied to a branch, and every branch gets its own function URL of the form https://<branch>-<function>.compute.<region>.aws.neon.tech.

Put those together and a branch is a self-contained backend: its own database, its own copy of the data, and its own API endpoint. Nothing it does touches the parent.

Proving the isolation

I have a small todos API (Hono + Drizzle on a Neon Function) already deployed on main, with a handful of rows. Here is the whole preview-backend lifecycle against it, with the real output.

That is the whole point in one sequence. The branch came up with its own function URL and a copy of main's four rows, a write landed only on the branch, main stayed at four, and deleting the branch cleaned up the database, the data, and the endpoint in one step. Every number there is from the real run.

Wire it into CI

The manual commands map directly onto pull-request automation. On open or update, create a branch named after the PR and deploy the function; expose the branch's function URL to your frontend preview as its API base; on close, delete the branch.

# .github/workflows/preview-backend.yml
name: preview-backend
on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

jobs:
  preview:
    runs-on: ubuntu-latest
    env:
      NEON_API_KEY: ${{ secrets.NEON_API_KEY }}
      BRANCH: pr-${{ github.event.number }}-preview
    steps:
      - uses: actions/checkout@v4

      # Create-or-update the branch and (re)deploy the function to it.
      - if: github.event.action != 'closed'
        run: |
          npx neon branches create --name "$BRANCH" || echo "branch exists"
          npx neon deploy --branch "$BRANCH"
          # Expose the branch's function URL to the frontend preview, e.g. as
          # an env var on the Vercel/Netlify deploy for this PR.

      # Tear it all down when the PR closes.
      - if: github.event.action == 'closed'
        run: npx neon branches delete "$BRANCH"

Now the frontend preview and the backend preview live and die together. Reviewers click a preview that is running that PR's real code against that PR's own database, seeded from a real copy of production data, and none of it can affect anyone else.

Shared staging vs a branch per PR

	Shared staging backend	Branch per PR
Isolation	One database for all PRs	Own database + data + URL per PR
Migrations	Collide across PRs	Run only against that branch
Data realism	Thin seed fixtures	Copy-on-write copy of real data
Teardown	Manual, scary, shared	Delete the branch, everything goes
Idle cost	An always-on staging box	Copy-on-write storage + scale-to-zero compute

Because a branch is copy-on-write, it does not duplicate your data on disk; it stores only what diverges. Combined with functions that scale to zero when idle, a preview backend for a PR that nobody is actively clicking costs close to nothing, which is what makes one-per-PR practical rather than a budget conversation.

The repo

The todos API used here (Hono + Drizzle on a Neon Function) is the same one from the first post in this series:

https://github.com/The-DevOps-Daily/neon-functions-demo

Wrapping up

Preview environments earned their reputation on the frontend, where every PR gets a clean, clickable, isolated build. The backend got left behind on shared staging, and that is where the confusing bugs and the migration standoffs come from. Because a Neon branch carries the schema, the data, and now the function together, you can give each pull request a real backend of its own and delete it on merge. The frontend preview finally talks to something as disposable and isolated as it is.

A Postgres-Backed MCP Server in ~20 Lines

DevOps Daily — Wed, 15 Jul 2026 14:46:58 +0000

The Model Context Protocol is how an AI agent gets tools. You stand up an MCP server, it advertises a set of tools with typed inputs, and the agent calls them. For a huge number of real MCP servers, those tools are thin wrappers around a database: search these records, create this row, update that field. The server is mostly a translator between JSON-RPC and SQL.

Which raises an obvious question. If an MCP server spends its life talking to Postgres, why does it so often run somewhere far away from Postgres? The usual setup is an MCP server on one host and the database on another, so every tool call pays a network round trip to reach the data it needs.

Neon Functions let you skip that. You deploy the MCP server as a function that lives on the same database branch it queries, in the same region, so the server-to-Postgres hop is a local one. In this post I build a Postgres-backed MCP server, deploy it onto a branch, connect a real MCP client, and show what the round trips actually look like. The whole thing is about twenty lines of interesting code, and the repo is at the end.

TL;DR

An MCP server that exposes database tools is mostly network plus queries. Running it next to the database removes a cross-region hop from every tool call.
Neon Functions deploy your MCP server onto a database branch, co-located with Postgres. The server-to-database query is a same-region hop of a millisecond or two, not a transatlantic one.
The core is small: define a Drizzle schema, register a tool whose handler runs a query, and expose the MCP server over the streamable HTTP transport at /mcp. That is the ~20 lines.
Any MCP client that speaks streamable HTTP connects to it: mcporter, the MCP SDK, or an agent like Claude or Cursor pointed at the URL.
Each branch gets its own function URL, so every preview or test branch can have its own isolated MCP endpoint over its own copy of the data.

Prerequisites

Node.js 20+ and the Neon CLI (npm i -g neon, then neon login)
A Neon account with the platform preview enabled (Functions, new us-east-2 projects)
Basic familiarity with Postgres and TypeScript
Optional: an MCP client to point at it, such as mcporter, Claude, or Cursor

What an MCP server actually is

Strip away the branding and an MCP server is a small RPC service. It speaks JSON-RPC over a transport, and it advertises a list of tools. Each tool has a name, a description, and an input schema. When the agent decides to call a tool, the server runs a handler and returns a result. That is the whole contract.

The transport here is streamable HTTP: the client POSTs JSON-RPC messages to a single endpoint (/mcp) and reads responses back, with server-sent events for anything streamed. It works over plain HTTPS, which is exactly what a serverless function serves, so an MCP server and a Neon Function are a natural fit.

The ~20 lines

Here is the core of a Postgres-backed MCP server. A schema, one tool whose handler runs a query, and the wiring to expose it over streamable HTTP. Everything else is more of the same.

import { Hono } from 'hono';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';
import { ilike } from 'drizzle-orm';
import { z } from 'zod';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StreamableHTTPTransport } from '@hono/mcp';
import { contacts } from './db/schema';

// One pool per isolate, reused across requests.
const db = drizzle(new Pool({ connectionString: process.env.DATABASE_URL }));

const mcp = new McpServer({ name: 'contacts', version: '1.0.0' });

mcp.registerTool(
  'search_contacts',
  {
    description: 'Search contacts by name. Omit the query to list everyone.',
    inputSchema: { query: z.string().optional().describe('substring to match') },
  },
  async ({ query }) => {
    const rows = await db
      .select()
      .from(contacts)
      .where(query ? ilike(contacts.name, `%${query}%`) : undefined);
    return { content: [{ type: 'text', text: JSON.stringify(rows) }] };
  },
);

// Expose the server over streamable HTTP at /mcp.
const app = new Hono();
const transport = new StreamableHTTPTransport();
app.all('/mcp', async (c) => {
  if (!mcp.isConnected()) await mcp.connect(transport);
  return transport.handleRequest(c);
});

export default app;

The tool handler is the interesting part. It is just a query. registerTool gives the agent the name, the description, and a Zod input schema (the SDK turns that into the JSON schema the model sees), and your handler returns content. The companion repo fills this out to full CRUD (create_contact, update_contact, delete_contact, search_contacts) against a small contacts table, but every tool follows this same shape: describe it, run a query, return the rows.

The schema is ordinary Drizzle:

import { pgTable, serial, text, timestamp } from 'drizzle-orm/pg-core';

export const contacts = pgTable('contacts', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email'),
  company: text('company'),
  notes: text('notes'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

And the function declaration that tells Neon what to deploy:

// neon.ts
import { defineConfig } from '@neon/config/v1';

export default defineConfig({
  preview: {
    functions: {
      contacts: { name: 'contacts mcp server', source: 'src/index.ts' },
    },
  },
});

Deploy it onto the branch

The Neon CLI scaffolds the template, links (or creates) a project, pushes the schema, and deploys the function. From an empty directory:

That last URL is the deployed MCP server. The function and the Postgres branch it queries are in the same region, us-east-2. The MCP endpoint is that URL plus /mcp. If you want to iterate before deploying, neon dev serves the same function locally at http://localhost:8787 with the MCP endpoint at /mcp.

A Neon Function has a public HTTPS URL, reachable by anyone who has it. This example runs open for the demo, which is not acceptable for anything real: these tools read and write your database. Gate the endpoint before you share the URL.

The gate is a few lines of Hono middleware in front of /mcp. The repo ships it env-gated: leave MCP_TOKEN unset and the demo stays open, set it and every request needs the bearer token.

app.use('/mcp', async (c, next) => {
  const token = process.env.MCP_TOKEN;
  if (token && c.req.header('authorization') !== `Bearer ${token}`) {
    return c.json({ error: 'unauthorized' }, 401);
  }
  await next();
});

Most MCP clients can send custom headers, so the agent side is one config line (Authorization: Bearer <token>). I verified the gate directly against the app: no header and a wrong token both get a 401, the right token passes through to the transport, and with MCP_TOKEN unset the endpoint behaves exactly as before.

Wire up a client and watch it work

Any MCP client that speaks streamable HTTP can connect to /mcp. Here are three ways: a CLI, the SDK, and adding it to an agent.

mcporter (CLI):

# List the tools the server advertises
mcporter list https://<branch>-contacts.compute.c-3.us-east-2.aws.neon.tech/mcp --schema

# Call a tool
mcporter call ".../mcp.create_contact" name="Ada Lovelace" company="Analytical Engines"
mcporter call ".../mcp.search_contacts" query="engine"

MCP SDK (Node):

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';

const url = new URL('https://<branch>-contacts.compute.c-3.us-east-2.aws.neon.tech/mcp');
const client = new Client({ name: 'test', version: '1.0.0' });
await client.connect(new StreamableHTTPClientTransport(url));

console.log((await client.listTools()).tools.map((t) => t.name));
const r = await client.callTool({ name: 'search_contacts', arguments: { query: 'ada' } });
console.log(r.content[0].text);

Claude / Cursor:

# Point an MCP-aware agent at the URL as a streamable HTTP server.
# add-mcp writes the client config for you:
npx add-mcp https://<branch>-contacts.compute.c-3.us-east-2.aws.neon.tech/mcp -a claude

# Then in the agent: "search my contacts for anyone at the Navy"

I ran the SDK client against the deployed server from a machine in Europe. The handshake and the tool calls all worked on the first try:

connect (initialize + handshake): ~1.5 s   (cold start ~2 s the first time)
tools/list: create_contact, update_contact, delete_contact, search_contacts
create_contact: 196 ms  ->  { "created": { "id": 1, "name": "Ada Lovelace", ... } }
search_contacts "navy": 150 ms  ->  { "count": 1, "contacts": [ { "name": "Grace Hopper", ... } ] }

A direct SELECT count(*) against the branch afterwards showed the rows really landed in Postgres. Nothing is held in memory; the tools are just queries.

Why co-location is the point

Those tool-call numbers are around 150 to 200 milliseconds, but that is a measurement of my distance to the function, not the function's speed. I am in Europe and the function is in us-east-2, so each call is roughly one transatlantic round trip. An agent running near the region, or the model provider's own infrastructure calling the tool, sees a small fraction of that.

The number that does not move with the client's location is the hop from the function to Postgres, and that is the one co-location fixes. In the first post in this series I measured exactly that: a SELECT from inside the function against the co-located branch ran in about 1.2 ms, versus about 135 ms for the same query issued across the Atlantic.

A tool call that runs one or two queries inherits that difference on every invocation. Put the MCP server a region away from its database and each tool call carries an extra cross-region round trip on top of whatever the client already paid to reach the server. Put the server on the branch and that part is effectively free. For a server whose entire job is querying Postgres, that is the hop worth optimizing.

One endpoint per branch

There is a second thing you get for free here. Neon Functions are deployed per branch, and each branch has its own function URL. Because a branch is also a copy of your data, that means every branch can have its own MCP server over its own dataset.

Spin up a branch for a preview environment and it comes with an MCP endpoint backed by that branch's data. Give an agent a scratch branch to work against and it cannot touch production. Run your CI against a branch and the agent's tools operate on the ephemeral copy, then it all gets thrown away with the branch. You are not standing up and tearing down a separate MCP service per environment; the endpoint rides along with the branch you already have.

The repo

The full example, with all four CRUD tools, the schema, the deploy config, and client test scripts, is here:

https://github.com/The-DevOps-Daily/neon-mcp-demo

Wrapping up

An MCP server that fronts a database is mostly network and queries, and the network part is worth taking seriously because an agent may call these tools dozens of times in a single task. Neon Functions let you collapse the server-to-database distance to a same-region hop by deploying the MCP server onto the branch it queries, and the code to do it is small: a schema, a tool that runs a query, and the streamable HTTP transport. Point any MCP client at the URL and the agent has typed, database-backed tools running right next to the data. Give each branch its own endpoint and you get isolated, per-environment agent tooling without any extra services to run.

Streaming an AI Agent Without a Function Timeout

DevOps Daily — Wed, 15 Jul 2026 14:16:30 +0000

An AI agent and a serverless function want different things. The agent wants to think, call a tool, stream some tokens, call another tool, and keep the connection open the whole time, which can be tens of seconds or more. A lot of serverless tiers want the opposite: do your work quickly and return, because the invocation has an execution cap. Put them together and you get the failure everyone who has shipped an agent has seen at least once: the response is still streaming when the platform decides time is up and closes the socket.

This is the second post in our series on Neon Functions. The first was about where your compute runs relative to your data; this one is about how long it is allowed to keep talking. Neon Functions are built to hold long-lived streaming connections, so a slow agent or a long stream is a normal request, not a fight with a timeout. To show it rather than assert it, I deployed two endpoints and measured them.

(Companion repo, deploy it yourself: The-DevOps-Daily/neon-streaming-demo.)

Two endpoints, one config

The whole backend is a single Hono function with the AI Gateway switched on in neon.ts:

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    aiGateway: true,
    functions: {
      stream: { name: 'streaming demo', source: 'src/index.ts' },
    },
  },
});

The streaming itself is ordinary Hono. The first endpoint holds a server-sent-events connection open and emits a tick every second, for as many seconds as you ask:

import { streamSSE } from 'hono/streaming';

app.get('/long-stream', (c) => {
  const seconds = Math.min(600, Math.max(1, Number(c.req.query('seconds') ?? '90')));
  const start = Date.now();
  return streamSSE(c, async (stream) => {
    for (let i = 1; i <= seconds; i++) {
      await stream.writeSSE({ event: 'tick', data: JSON.stringify({ tick: i, elapsed_ms: Date.now() - start }) });
      await stream.sleep(1000);
    }
    await stream.writeSSE({ event: 'done', data: JSON.stringify({ ticks: seconds }) });
  });
});

It streamed for 90 seconds without being asked twice

I called /long-stream?seconds=90 and let it run. It ticked once a second, on the second, for a minute and a half, and closed cleanly on its own terms:

Ninety seconds is not a magic number; I picked it because it is comfortably past the execution cap a lot of serverless functions ship with by default, and the function did not care. No special mode, no config flag, no "streaming response" opt-in. The handler just held the connection.

To be precise about the comparison: this is about defaults and design, not "infinite versus finite." Traditional serverless functions cap a single invocation low by default (Vercel's Hobby tier at 10 seconds, Pro at 60), which is exactly where a slow agent gets cut off. Platforms do offer longer runs when you reach for them: Vercel's Fluid Compute extends to 300 to 1800 seconds, and AWS Lambda allows up to 15 minutes. The point is that long-lived streaming is the default behaviour of a Neon Function, not a setting you discover after your agent times out in production.

Now stream an actual agent

A ticking clock proves the connection lasts. The real workload is a model streaming tokens. The second endpoint sends the prompt to the Neon AI Gateway with stream: true and relays each token to the caller as it arrives:

const upstream = await fetch(`${process.env.NEON_AI_GATEWAY_BASE_URL}/ai-gateway/mlflow/v1/chat/completions`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.NEON_AI_GATEWAY_TOKEN}`, 'content-type': 'application/json' },
  body: JSON.stringify({ model: 'gpt-5-nano', stream: true, messages }),
});
// ...parse the upstream SSE and re-emit each delta as it lands
await stream.writeSSE({ event: 'token', data: JSON.stringify({ delta }) });

Calling it with a small prompt, the first token came back at 466 ms and the full 62-token reply finished at about 2.0 seconds. The reader sees the answer forming almost immediately instead of waiting two seconds for a wall of text:

Two seconds is short because the model and the prompt are small. The reason this matters is that real agents are not short: they make several model calls, run tools between them, and a full run is routinely tens of seconds. On a platform that caps invocations at 10 or 60 seconds, that run is a gamble against the clock. On a function built to hold the stream, it is just a request that takes a while.

What it is, and what it is not

Private preview, one region, new projects only. Everything is in AWS us-east-2 and only works on projects created inside the preview. Plan accordingly before building on it.

Two more things worth knowing before you reach for this:

It is request/response, even when the response is long. These functions answer a caller and can keep streaming to it for a long time, including over WebSockets and SSE. They are not a background job runner. Work that should outlive the request (queues, retries, scheduled tasks) belongs to something like Inngest or QStash.
Idle functions can be evicted. A long active stream is fine; a function sitting idle may be scaled to zero and cold-start on the next call. That is the usual serverless tradeoff, not a streaming-specific one.

Who this is for

If you are shipping anything agentic (a chat assistant, a tool-using agent, a long generation, an MCP server holding a session), the timeout is the wall you hit first, and the usual workaround is to learn your platform's extended-duration mode and hope you configured it right. A function that holds the stream by default removes that whole category of "why did my response get cut off" debugging.

The full demo, both endpoints, is here. The streaming logic is about 80 lines:

https://github.com/The-DevOps-Daily/neon-streaming-demo

Next in the series: a Postgres-backed MCP server in about twenty lines, and preview environments that include the backend, not just the frontend. The strategy behind all of it is in Neon is becoming a backend platform, not just Postgres.

Compute That Lives on Your Database Branch

DevOps Daily — Wed, 15 Jul 2026 12:59:23 +0000

Ask where your backend code runs relative to your database and the answer is often "somewhere else." Your function is in one provider's us-east-1, your Postgres is in another region entirely, and every query crosses that gap. Most of the time you don't see it, because one query is fast enough to ignore. Then a request makes eight queries in sequence, each pays the round trip, and suddenly an endpoint that should take milliseconds takes most of a second.

Neon Functions, part of Neon's June 2026 platform preview, takes a different position: run the compute in the same region as the database branch, on a URL scoped to that branch. This is the first in a series on what that buys you. It is also the simplest to demonstrate, because the benefit is something you can measure. I deployed a small REST API and timed a trivial query two ways. The numbers are at the bottom, and they are not close.

(Companion repo, deploy it yourself: The-DevOps-Daily/neon-functions-demo.)

The whole backend is one config file

Neon ships starter templates through its CLI. The REST API is one of them:

What gets deployed is declared in neon.ts. For this API it is three lines of intent: take src/index.ts and run it as a function called todos.

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    functions: {
      todos: { name: 'todo api', source: 'src/index.ts' },
    },
  },
});

No connection string in there, no region to pick for the compute, no URL to reserve. The DATABASE_URL is injected at deploy time, and the function lands in the same region as the branch automatically.

The function is a normal web handler

There is nothing Neon-specific in the application code. It is a standard Hono app talking to Postgres through a connection pool, the same code you would write for any Node host:

import { Hono } from 'hono';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';
import { parseEnv } from '@neondatabase/env';
import config from '../neon';
import { todos } from './db/schema';

const env = parseEnv(config);
const pool = new Pool({ connectionString: env.postgres.databaseUrl, max: 5 });
const db = drizzle(pool);

const app = new Hono();
app.get('/todos', async (c) => c.json(await db.select().from(todos)));
app.post('/todos', async (c) => {
  const { text } = await c.req.json<{ text: string }>();
  const [row] = await db.insert(todos).values({ text }).returning();
  return c.json(row, 201);
});

export default app;

After neonctl deploy, that handler answers at a branch-scoped URL, and the create/read path works end to end:

curl -X POST "$URL/todos" -H 'content-type: application/json' -d '{"text":"ship it"}'
# {"id":1,"text":"ship it","createdAt":"2026-06-25T16:17:10.692Z"}  (201)
curl "$URL/todos"
# [{"id":1,"text":"ship it","createdAt":"2026-06-25T16:17:10.692Z"}]  (200)

The phrase "branch-scoped URL" is the part worth slowing down on. Open a branch off this one and it gets its own function at its own URL, running your latest code against that branch's data. The preview environment for a pull request stops being "the frontend plus a shared backend" and becomes a real, isolated copy. We will spend a whole post on that later; for now, the point is that the function and the branch are one unit.

Now measure the distance

Here is the part you can put a number on. The function exposes a /db-latency endpoint that times thirty SELECT 1 round trips from inside the handler and returns the median. Because the function runs in the same region as the branch, this is the local hop:

curl "$URL/db-latency"
# { "from": "neon function (us-east-2, co-located with Postgres)",
#   "runs": 30, "min_ms": 1.13, "median_ms": 1.19, "p95_ms": 1.62 }

Just over a millisecond. Then I ran the exact same SELECT 1, against the exact same database, from a machine in Europe (this site's build box, a Raspberry Pi a long way from us-east-2):

# same query, same database, from a machine on another continent
# { "from": "europe -> us-east-2", "runs": 30,
#   "min_ms": 130.46, "median_ms": 134.54, "p95_ms": 138 }

Same query, same database. The only thing that changed is where the caller sits.

About 113x. And that is for one round trip. A request that reads a session, loads a user, fetches their settings, and runs three more queries pays that distance once per query if it runs them in sequence. At 1.2 ms the six-query endpoint spends roughly 7 ms talking to the database; at 135 ms it spends most of a second, and no amount of application tuning fixes it, because the time is in the network. This is the tax co-located compute removes. It is also where a lot of "serverless Postgres is slow" folklore actually comes from: not the database, but a function in one region reconnecting to a database in another on every cold start.

To be fair about the comparison: a real deployment is rarely as far away as Europe-to-Virginia. If your Lambda and your database are both in us-east-1 the gap is smaller. But "both in the same region" is exactly the property Neon Functions give you by default instead of by careful configuration, and "smaller" is not "zero."

What it is, and what it is not

A few things are worth stating plainly before you build around this, because it is a private preview and it has clear edges.

Private preview, one region, new projects only. Everything is in AWS us-east-2 and only works on projects created inside the preview. You cannot turn this on for an existing production database today.

Beyond that:

These are request/response functions, not a job runner. They are built for APIs, agents, webhooks, and real-time connections (they support streaming and long-lived sockets, not just quick replies). Background work, queues, retries, and schedules are a different kind of compute; pair them with something like Inngest or QStash.
Function memory is fixed (2048 MiB at preview), so this is not yet a knob-for-everything compute platform.
It is a Neon-shaped commitment. One config file declaring your functions is convenient precisely because it is integrated. That is coupling, traded for the locality and the branching.

Who this is for

If your backend already lives in mature infrastructure-as-code with compute and database carefully placed in the same region, Neon Functions are not solving a problem you have. You already paid the cost to make the hop short.

The teams this helps are the ones who never got around to that: side projects and small teams whose compute and database drifted into different regions because nobody decided otherwise, and anyone who wants a pull request to spin up a genuinely isolated backend without wiring it by hand. For them, "the function runs next to the database, on this branch's data, at this URL" is a real reduction in both latency and moving parts, and it is the default rather than a configuration you have to get right.

We dig into the bigger picture in Neon is becoming a backend platform, not just Postgres, and the rest of this series walks through the other things a branch-scoped function unlocks: streaming agents, MCP servers, and preview environments that include the backend. The full demo, including the /db-latency endpoint, is here:

https://github.com/The-DevOps-Daily/neon-functions-demo

The Everything-on-Your-Branch Architecture

DevOps Daily — Wed, 15 Jul 2026 12:27:47 +0000

Database branching is one of the best ideas serverless Postgres brought to the mainstream. Fork the database at a point in time, get an isolated copy with all the data, run something risky against it, throw it away. It made preview databases and safe migrations feel routine.

But a real application is not just a database. It is a database, plus the files it stores in object storage, plus the backend code that serves it, plus, increasingly, the model and gateway config it calls for AI. When you branch only the database, those other three stay shared. Your "branch" points at the same S3 bucket, the same deployed backend, and the same AI configuration as everything else. So it is half a copy, and the half it leaves out is where a lot of the interesting bugs and the scary migrations live.

Neon's platform preview changes what a branch contains. A branch now forks the database and its data, the object storage and its files, the functions that run your backend, and the AI gateway config, all at the same point in time, all isolated. A branch stops being a database copy and becomes a whole environment. To make sure that is a real claim and not a diagram, I took a full-stack project, branched it, and checked every layer. Here is what happened.

TL;DR

Elsewhere, "branch" means the database only. Object storage, backend deploys, and AI config stay shared, so you bolt on scripts to fake per-branch versions of them.
A Neon branch forks all four together: Postgres + data, object storage + files, functions (each branch gets its own URL), and the AI gateway.
I proved it: branched a project with a DB, a bucket of files, a function, and the gateway. The branch came up with a copy of the rows, a copy of the files on its own storage endpoint, its own function URL, and the gateway. A write to the branch left main untouched, and deleting the branch removed all of it.
That makes a branch a real environment: true preview stacks, whole-state bug reproduction, and disposable sandboxes for agents.
Copy-on-write storage and scale-to-zero compute keep an idle branch close to free, which is what makes one-per-PR or one-per-experiment practical.

Prerequisites

A Neon project on the platform preview (Functions, object storage, AI gateway; us-east-2)
The Neon CLI (npm i -g neon, then neon login)
Comfort with Postgres, S3-style object storage, and serverless functions

What branches today, and what doesn't

Database branching is now common. What is not common is branching everything around the database. In a typical stack:

The database branches. Good.
The object storage does not. Your branch reads and writes the same real bucket, so a preview can overwrite or delete production files, and you cannot fork the files to match the forked rows.
The backend does not. The branch talks to whatever backend is deployed, usually shared staging, so the code and the data are versioned separately.
The AI / model config does not. Keys, model routing, and spend are shared, so a preview's experiments bill against the same budget and there is no per-branch isolation.

Teams paper over this with scripts: a bucket-prefix-per-branch convention, a bespoke deploy step, a separate set of keys. It works, sort of, and it is a pile of glue nobody wants to own.

What a Neon branch forks now

On Neon's platform preview, one branch carries the whole stack:

The database and storage are copy-on-write, so the branch starts as a reference to the parent's state and only stores what you change. The function redeploys onto the branch with its own URL. The gateway config comes along. Delete the branch and every layer goes with it.

Proving it, layer by layer

I used a small AI image-agent project that exercises all four services: a Postgres table, an images object-storage bucket with real files in it, an imagegen function, and the AI gateway. Then I branched it and inspected each layer. Every line below is from the real run.

The parts that matter: the deploy reported Utilized services: Postgres, Object Storage, Functions, AI Gateway, so all four came along. The branch got a separate storage endpoint from main (not the same bucket with a prefix, an actual isolated endpoint) carrying a copy of the files. It got its own function URL. And the file I wrote to the branch never appeared on main, the same isolation the rows get. Deleting the branch took the whole environment with it.

I used the AWS CLI shape above for readability; in the actual run I drove object storage with the S3 SDK against the branch-scoped AWS_ENDPOINT_URL_S3 that neon deploy writes into .env.local. The credentials and endpoint are per branch.

Why an environment beats a database copy

Once a branch is the whole stack, a few things that used to need real infrastructure become one command:

Preview environments that are actually complete. Every PR can get its own database, its own files, and its own backend URL, not a frontend pointed at shared staging. (This is the preview-backend workflow from earlier in the series, now including storage and models too.)
Whole-state bug reproduction. Fork production's database and its files together and you can reproduce a bug that depends on a specific row pointing at a specific uploaded object. Branching the DB alone would leave the file behind.
Migrations you can trust. Test a schema change against a copy of the data and the files it references, on a throwaway backend, before it touches production.
Disposable sandboxes for agents. Give an AI agent a branch and it gets a full environment (data, files, compute, models) it cannot use to damage anything real. Delete it when the task is done.

The mental model shift

The useful reframe is to stop thinking of a branch as "a copy of my database" and start thinking of it as "a copy of my environment." Because storage and database are copy-on-write, that environment does not duplicate anything on disk until it diverges, and because functions scale to zero, an idle branch costs almost nothing. That combination is what makes it reasonable to spin up a full environment per pull request, per experiment, or per agent task and delete it without a second thought.

This is Neon's platform preview: object storage, functions, and the AI gateway are available on new us-east-2 projects. The database-branching half works everywhere; the "everything else branches too" half is what the preview adds.

The repo

The full-stack demo used here (Postgres + object storage + function + AI gateway, from one CLI) is the companion to the earlier flagship in this series:

https://github.com/The-DevOps-Daily/neon-ai-agent

Wrapping up

Branching taught us to treat a database as something you can fork and throw away. The catch was always that the database was only part of the application, so a branch was only part of a copy. When the branch also carries the files, the backend, and the model config, it becomes a real, disposable environment, and the workflows that used to justify a pile of staging infrastructure, preview stacks, safe migrations, faithful bug repro, agent sandboxes, collapse into create a branch and delete a branch. That is the shift worth paying attention to: not a better database copy, but a forkable environment.

Neon Is Becoming a Backend Platform, Not Just Postgres

DevOps Daily — Wed, 01 Jul 2026 15:30:52 +0000

For most of its life, Neon had a one-sentence pitch: serverless Postgres that branches like Git. You got a database that scaled to zero, forked in milliseconds, and charged you for what you used. Everything else (your compute, your file storage, your AI calls, your auth) you wired up somewhere else and pointed at the connection string.

In June 2026 that sentence got longer. Neon shipped a private preview that adds three new surfaces around the database: serverless Functions, S3-compatible Storage, and an AI Gateway for model calls. A fourth, Neon Auth, shows up in the templates. None of these is novel on its own. Functions look like Lambda, storage looks like S3, an AI gateway looks like a dozen other AI gateways. The reason it is worth a closer look is the through-line connecting them, and that through-line is the same primitive Neon already built its name on: branching.

This is an analysis of what actually shipped, what it replaces, and where it is still clearly a preview. I created a new project and deployed against it while writing this, so the specifics below are from the real thing, not the marketing page.

What shipped

Four pieces, all in private preview, all in AWS us-east-2, all for new projects only.

Neon Functions are Node.js compute deployed onto a database branch. You declare them in a neon.ts config file, write a standard Fetch-API handler (Hono is the recommended framework), and run neonctl deploy. Each branch gets its own function URL, the DATABASE_URL is injected automatically, and the function runs in the same region as the branch, so there is no cross-region hop to the database. They support streaming and long-lived connections (WebSockets, server-sent events), which is the deliberate split from request-scoped serverless: these are not for background jobs, they are for request/response and real-time work.

Neon Storage is S3-compatible object storage. Your existing AWS SDK, boto3, or aws CLI talk to it unchanged. The twist is that storage is scoped to a branch, so when you fork a database branch, its files fork with it.

Neon AI Gateway is a single credential that fronts models from Anthropic, OpenAI, Google, and a few open-source providers. The OpenAI and Anthropic SDKs work without code changes; you point them at a per-branch gateway endpoint. The published catalog lists around 25 models, priced per million tokens at what look like each provider's own list rates (Claude Haiku 4.5 at $1/$5 in/out, GPT-5 Nano at $0.05/$0.40, Gemini 2.5 Flash at $0.30/$2.50).

Neon Auth rounds it out with authentication that does not require standing up a separate identity service, used in the realtime-chat template alongside Next.js.

The through-line is branching

Take those four features and the obvious read is "Neon is cloning Supabase," or "Neon is becoming Vercel with a database." Both are partly true and both miss the point. The organizing idea is that every one of these surfaces inherits database branching.

A Neon branch already gave you an isolated copy of your data in milliseconds, with copy-on-write so it was cheap. Now that same branch gives you:

an isolated function at its own URL, running your latest code against that branch's data,
an isolated storage namespace, so files written in a preview branch never touch production objects,
an isolated AI Gateway endpoint, so model usage on a feature branch is its own thing.

That is the part you cannot easily assemble from separate vendors. You can stitch Lambda, S3, an AI gateway, and an auth provider together yourself, plenty of teams have. What you cannot easily do is make all of them fork in lockstep when you open a pull request, and then throw the whole set away when the branch merges. The preview environment stops being "a copy of the database plus a pile of shared, mutable infrastructure" and becomes a genuinely isolated copy of the backend.

If you have ever had a preview deployment write a test file into the production S3 bucket, or seen a staging job run up a bill against the same AI key as prod, you already understand why branch-scoped everything is the actual feature here.

What it replaces, and the tax it removes

The clearest way to see the value is to count the moving parts in a typical "branchable AI app" today versus on this platform. Standing up one environment the assemble-it-yourself way usually means a database, a compute host, an object store, a few model-provider keys, and an auth service, each with its own account, credential, and region to keep in sync.

That count is illustrative, not measured: your stack may have more or fewer pieces. But the direction is the real claim. Every separate service is another credential to rotate, another thing to provision per preview environment, and another place for prod and staging to accidentally share state. Collapsing that to one account with auto-injected, per-branch credentials is less a feature than the removal of a tax you have been quietly paying.

There is a second, quieter tax it removes: distance. Because functions run in the same region as the branch, the function-to-database round trip is local. A lot of "serverless Postgres is slow" folklore is really "my Lambda in one region is talking to my database in another, over a connection it has to re-establish on every cold start." Co-locating the compute with the branch sidesteps that specific problem.

Where the seams still show

This is a private preview, and it reads like one. Worth being clear-eyed about the limits before you plan anything around it.

One region, new projects only. Everything is in AWS us-east-2 and only works on projects created after the preview opened. Your existing Neon databases will not grow these features in place, which matters if you were hoping to bolt functions onto a production project.

Functions are not a job runner. They are explicitly request/response and real-time, not background jobs. Queued, retryable, cancellable work still belongs to something like QStash or Inngest. That is an honest scoping decision, but it means "move my whole backend here" is not yet on the table.
Fixed function sizing. Memory is fixed (2048 MiB at preview), so this is not a knob-for-everything compute platform yet.
Billing is half-documented. The per-model token prices are public and look like pass-through, but Neon has not publicly spelled out whether there is a markup or preview credits on the AI Gateway. For a side project that is noise; for a budget forecast it is a question to ask before you commit.
Lock-in is the real trade. The whole pitch is integration: one config file, one credential, everything branching together. That convenience is also coupling. An S3-compatible API and standard SDKs keep the exit ramps wider than a fully proprietary stack would, but a neon.ts that declares your functions, buckets, and gateway is, by design, Neon-shaped.

Who should actually care

If you run a large, already-wired backend with mature infrastructure-as-code, none of this is urgent. You have solved preview environments, even if the solution is a pile of Terraform and a shared staging bucket.

The teams this is aimed at are the ones for whom that pile is the problem. Specifically:

Anyone building agents. An agent wants a database to remember things, compute that can stream tokens without a timeout, storage for what it generates, and model access. Getting all four from one CLI, branchable together, is a genuinely shorter path than assembling them. It is not a coincidence that the flagship templates are agents and MCP servers.
Teams that live in preview environments. If every pull request should get a real, isolated backend and yours currently get a database copy plus shared everything-else, branch-scoped functions and storage close that gap.
Small teams shipping AI features. The combination of "Postgres you already use" and "model calls without managing three provider accounts" removes a couple of the most annoying setup steps.

The honest framing is that Neon is making a bet: that the database, not the compute platform, is the right center of gravity for a backend, because the database is where your state and your branching already live. Vercel is making the opposite bet from the compute side, and Supabase has been making a similar bundled-backend bet for years. Whether "everything branches with your data" is a durable advantage or a feature others copy, the next year will tell.

For now, the thing to internalize is that "Neon" no longer means "a Postgres host." It means a database with compute, storage, and model access growing out of it, all sharing the one trick Neon was already good at. If you have only ever evaluated it as a place to put a connection string, it is worth a second look on those terms.

We benchmark Neon's database side in depth in our Neon vs Supabase series, and keep a running Neon vs Supabase comparison covering architecture and pricing side by side. As these platform features leave preview, we will put them through the same treatment: real projects, real numbers, and the harness published so you can argue with our data instead of someone's vibes.

Stop Using Random UUIDs as Primary Keys: uuidv7() Lands in PostgreSQL 18

DevOps Daily — Wed, 01 Jul 2026 15:26:27 +0000

If you reach for gen_random_uuid() every time you need a primary key, you have probably never measured what it costs. On a small table, nothing. On a table with tens of millions of rows, random UUIDs turn every insert into a random write into the middle of your primary-key index, and that quietly drags down insert throughput, inflates index size, and burns through cache and WAL.

PostgreSQL 18 fixes the root cause with a native uuidv7() function. UUIDv7 is time-ordered, so new keys land at the right-hand edge of the B-tree like a sequential bigint would, while keeping the properties teams pick UUIDs for in the first place: generate them anywhere, no central sequence, no coordination. This post explains why the random version is slow, what changes with v7, the benchmark numbers on a 50-million-row table, the one real tradeoff, and how to adopt it without rewriting your schema.

TL;DR

uuidv4() (random) primary keys scatter inserts across the whole index. On large tables that means constant page splits, low page density, fragmentation, and write amplification.
PostgreSQL 18 adds uuidv7(), a time-ordered UUID per RFC 9562. New rows append at the index's right edge, like a sequential key.
In one published 50M-row benchmark, the initial bulk insert finished in about 1.8 minutes with v7 versus about 20 minutes with v4, and the index was roughly 25 percent smaller. Range scans by id ran about 3x faster.
The one real catch: a v7 value embeds its creation time, so do not hand it out as a public identifier if creation time is sensitive.
bigint is still smaller and faster than any UUID. Use uuidv7() when you actually need UUID properties, not as a reflex.

Prerequisites

PostgreSQL 18 (the uuidv7() function is built in; no extension needed)
Basic familiarity with B-tree indexes and primary keys
A schema where you are choosing or reconsidering a primary-key type
Optional: pg_stat_statements and \timing if you want to measure on your own data

Why random UUIDs are slow as primary keys

A primary key in PostgreSQL is backed by a B-tree index, and a B-tree stays sorted by key. Where a new key lands in that sorted structure is the whole story.

A bigint from a sequence always sorts after the previous one, so every insert lands at the right-hand edge of the tree. That rightmost page stays hot in memory, fills up, and splits cleanly. A random UUIDv4 has no order at all, so each insert lands at a random leaf page somewhere in the index.

UUIDv4 (random)                       UUIDv7 / bigint (ordered)
inserts scatter across the tree       inserts append at the right edge

      [ root ]                              [ root ]
     /   |   \                             /   |   \
  [p1] [p2] [p3] ...                    [p1] [p2] [p3] [hot]
   ^    ^      ^                                        ^
  write write write                              every write here
  (cold pages pulled in,                         (one hot page, stays
   split, half-empty)                             in cache, fills, splits clean)

That random-write pattern has three compounding costs on a large table:

Page splits and low density. Inserting into the middle of a full page splits it, leaving both halves partly empty. Your index ends up larger than the data it indexes and full of slack.
Cache misses. The working set is the entire index, not a hot tail. Once the index no longer fits in shared_buffers, every insert risks a random read from disk to fetch the target page.
WAL and full-page-image amplification. The first write to a page after a checkpoint logs the whole page. More distinct pages touched per second means more full-page images and more WAL.

None of this shows up at 10,000 rows. It shows up exactly when the table gets big enough to matter.

What uuidv7() changes

A UUIDv7 is laid out so the most significant bits are a timestamp. PostgreSQL 18 builds it from a 48-bit Unix millisecond timestamp, then a sub-millisecond fraction, then random bits, following RFC 9562. Because the timestamp is at the front and UUIDs sort lexically as 128-bit values, a v7 generated now always sorts after one generated a moment ago.

The result is that v7 keys behave like a sequence for index-locality purposes. Inserts append at the right edge, the hot page stays in cache, and pages fill before they split. You get the write pattern of a bigint with the generate-anywhere property of a UUID.

PostgreSQL 18 exposes three functions. The names are now explicit about the version:

-- Version 4, random. These two are equivalent.
SELECT gen_random_uuid();      -- 5b30857f-0bfa-48b5-ac0b-5c64e28078d1
SELECT uuidv4();               -- b42410ee-132f-42ee-9e4f-09a6485c95b8

-- Version 7, time-ordered. New in PostgreSQL 18.
SELECT uuidv7();               -- 019535d9-3df7-79fb-b466-fa907fa17f9e

-- Optional interval shift, handy for backfilling historical rows
-- with timestamps in the past.
SELECT uuidv7(shift => '-7 days'::interval);

One useful detail: within a single backend session, PostgreSQL guarantees each uuidv7() it generates is strictly greater than the last, by spending some of the random bits on extra clock precision. So even a tight insert loop produces monotonic keys rather than occasionally colliding on the same millisecond.

The numbers

The performance argument is not subtle. Credativ published a detailed comparison on PostgreSQL 18 using a single-column UUID primary key and 50 million rows. The initial bulk load is the headline:

The index size gap is just as real, and it widens when you insert into a table that already holds data, which is the normal case in production:

Reads benefit too. In the same benchmark, a range scan ordered by the id column ran roughly three times faster on v7 (about 113 ms versus 318 ms for a million-row ORDER BY id) and needed on the order of 100 times fewer buffer hits, because rows created near each other in time also sit near each other on disk. That locality is something a random UUID can never give you.

Two caveats on the numbers. They come from one benchmark on a synthetic single-column table, so treat the exact figures as directional rather than a promise for your workload. And the gap is smallest on tiny tables and largest on big ones, which is the whole point: this is a problem that scales with you.

uuidv7 vs uuidv4 vs bigint

uuidv7() is not automatically the right choice. It sits between the other two options.

	bigint sequence	uuidv4 (random)	uuidv7 (time-ordered)
Size	8 bytes	16 bytes	16 bytes
Insert locality	Sequential (best)	Random (worst)	Sequential
Generate without the DB	No	Yes	Yes
Reveals row count or order	Yes	No	Partially (creation time)
Leaks creation time	No	No	Yes

The short version:

Reach for bigint when a single database owns the sequence and you do not need to generate ids elsewhere. It is half the size of any UUID and the fastest option. The downside is that sequential integers leak how many rows you have and are trivially enumerable.
Reach for uuidv7() when you want UUIDs: ids generated by clients or multiple services, merged across shards, or created before a row reaches the database. It gives you that with almost none of the write penalty of v4.
Reach for uuidv4() only when you specifically need an identifier that reveals nothing, including when the row was created.

The one real catch: v7 leaks creation time

Because the timestamp sits in the high bits, anyone holding a v7 value can read roughly when it was generated. That is fine for an internal primary key. It is not fine if you expose the same value as a public identifier and the creation time is sensitive, for example a user id where signup time is private, or an order id where a competitor could infer your daily volume by diffing two ids.

Do not assume a UUID is opaque just because it looks random. A uuidv7() embeds a millisecond timestamp you can decode in seconds. If an identifier is shown to users or third parties and its creation time is sensitive, keep uuidv7() as the internal primary key and expose a separate uuidv4() (or another opaque token) externally.

This is a design decision, not a reason to avoid v7. Most primary keys never leave the backend, and for those the timestamp is a feature, not a leak.

How to adopt it

For new tables, set the column default and move on:

CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id uuid NOT NULL,
    total_cents integer NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

INSERT INTO orders (customer_id, total_cents)
VALUES (uuidv7(), 4999)
RETURNING id;

For an existing table that already uses random UUIDs, you do not need a risky rewrite. The existing rows keep their v4 values and stay scattered, but every new row inserted with a v7 default lands in order, so the index stops degrading from that point forward. Switch the default:

-- New rows get time-ordered ids; old rows are untouched.
ALTER TABLE orders ALTER COLUMN id SET DEFAULT uuidv7();

If you want the full benefit on historical data, you can rebuild the table or index during a maintenance window so the existing rows are stored in key order, but for many teams simply changing the default and letting the table grow in order is enough.

A few adoption notes:

Application-side generation still works. If your services generate ids before inserting, switch the client library to a UUIDv7 generator. Most language ecosystems now have one, and the database does not care who produced the value as long as it is a valid v7.
ORMs are catching up. Check whether your ORM lets you set a database default expression for the id column; if so, DEFAULT uuidv7() is the cleanest path. If it generates ids in application code, point it at a v7 library.
You do not need PostgreSQL 18 to start. If you are on 14 to 17, you can adopt UUIDv7 today by generating it in the application or with a small SQL function, then the upgrade to 18 just lets you drop that shim for the native function. Plenty of managed Postgres is already on 18 as well (Neon, for example, defaults new projects to Postgres 18), so you can try uuidv7() on a fresh database without upgrading anything yourself.

Key takeaways

Random UUIDv4 primary keys are a silent scaling tax: random index writes mean page splits, bloated indexes, cache misses, and extra WAL once a table gets large.
PostgreSQL 18's uuidv7() is time-ordered, so inserts append at the index edge like a sequence while keeping the generate-anywhere property of a UUID. Published benchmarks show large insert-time and index-size wins on 50M rows.
bigint is still the smallest and fastest key when one database owns the sequence; use uuidv7() when you genuinely need UUIDs, and uuidv4() only when you must hide creation time.
Adopting it is a one-line default change for new rows, with no rewrite required for existing tables. The main thing to design around is that v7 embeds a decodable timestamp, so keep it off public-facing identifiers when that matters.

Neon vs Supabase Pricing: What the Same App Costs From Launch to Scale

DevOps Daily — Fri, 26 Jun 2026 13:54:18 +0000

Pricing pages answer the question "what does a unit cost". They are conspicuously silent on the question you actually have: "what will my application cost in a year, when it has real users?" The honest answer depends on workload shape, and workload shape changes as you grow, which is why the same two platforms can each be the cheap option at different points in the same product's life.

This is part three of our Neon vs Supabase series (free tiers, operational benchmarks). Instead of benchmarking operations, we built a cost model: one application, five growth stages, priced on Neon Launch and Supabase Pro using list prices we verified against both pricing pages this week. The model is open source in the same repo as the benchmarks (npm run costs), every price carries its source, and you can change the workload assumptions and rerun it for your own product.

TLDR

There are three cost regimes, not one winner: Neon wins early (scale-to-zero means a quiet app costs almost nothing), Supabase wins the middle (a flat fee beats usage billing once the database runs hot but small), and Neon wins at scale by a wide margin.
The two crossover points sit roughly where your app stops sleeping (Supabase becomes competitive) and where your user count passes Supabase's included 100k monthly active users (Supabase stops being competitive, fast).
The scale-stage surprise: on Supabase, the database is not the bill. Metered auth MAU is. Our scale stage prices at $1,213/month on Supabase Pro, of which $975 is MAU overage; the same stage on Neon Launch is $278, because Neon Auth carries no per-MAU meter up to 1M users.
This comparison assumes you use each platform's bundled auth. If you bring your own auth provider, the picture changes substantially in Supabase's favor, and we show you where.

The application and its growth

The model prices one hypothetical B2B SaaS through five stages, with the workload dimensions both platforms bill on: average compute demand, how much of the month the database is actually active, database size, monthly active users on auth, preview branches created by CI, and egress.

Stage	Compute (avg)	Active time	DB size	MAU	Branches/mo	Egress
Launch month	0.25 CU	20%	1 GB	500	10	5 GB
First customers	0.25 CU	45%	5 GB	5k	30	25 GB
Product-market fit	0.5 CU	75%	20 GB	30k	60	100 GB
Growth	1 CU	95%	60 GB	120k	120	400 GB
Scale	2 CU	100%	200 GB	400k	200	1.5 TB

Disagree with the assumptions? Good: they are parameters, not conclusions. Clone the repo, edit the scenario, rerun. The shape of the findings survives reasonable changes to the numbers; your exact crossover points will differ.

The curves

Monthly cost of the same application as it grows — interactive version on DevOps Daily

Regime one, the quiet months. At launch, Neon costs $5 to Supabase's $26. Nothing clever: Supabase Pro is a $25 flat fee plus always-on compute, while Neon bills compute only when the database is awake, and an early-stage app sleeps most of the month. If you are pre-revenue, this gap is your hosting budget.

Regime two, the flat-fee window. By product-market fit the picture inverts: Supabase $33, Neon $49. The database now runs three-quarters of the month, so scale-to-zero stops paying, while Supabase's fixed fee covers a Small instance running around the clock with most usage inside included quotas. This is the regime Supabase's pricing is designed for, and in it, the design works. The growth stage is nearly a tie ($128 vs $120), which is itself useful information: between roughly 30k and 120k users, price should not be the deciding factor at all; pick on the operational differences instead.

Regime three, the meters. At scale the curves split violently: $278 on Neon, $1,213 on Supabase. To see why, look at where the Supabase dollars go:

Where the money goes at the scale stage (Supabase Pro, $1213.39/mo total) — interactive version on DevOps Daily

The MAU surprise

That chart is the article. At 400k monthly active users, the compute (a Medium instance, $50 after credits) and even 200 GB of storage ($24) are rounding errors next to $975 of MAU overage: Supabase Auth includes 100k monthly active users on Pro and bills $0.00325 for each one beyond. Auth, the feature that felt free when you started, becomes 80% of the bill precisely when your product succeeds.

Neon's side has no equivalent meter: Neon Auth (in beta) carries no per-MAU billing up to one million users on the paid plans, so the scale stage is honest compute and storage: $155 + $70 + $53 of always-active database, branches included.

Now the fairness flip, because this cuts both ways: the comparison above assumes you use the bundled auth. Plenty of teams run Clerk, Auth0, WorkOS, or their own auth regardless of database, and at 400k MAU those run hundreds to thousands of dollars a month on their own. If you bring your own auth, delete the MAU line from the Supabase column, and the scale stage becomes roughly $238 vs $278: a near-tie that Supabase arguably wins. The platform decision and the auth decision are one decision wearing two coats; make them together.

What the model deliberately leaves out

The PITR add-on ($100/month on Supabase per 7-day window): add it if sub-minute recovery is a requirement; part two explains what you get on each platform without it.
Replacement costs for the rest of the bundle: if you would otherwise pay for storage, realtime, or edge functions separately, Supabase's flat fee is buying more than a database. Neon announced its own storage and functions in June 2026, but they have not shipped.
Committed-use and enterprise discounts, support tiers, and the Team/Scale tiers above these plans: that comparison is coming later in this series.
Egress shape: we model it linearly; a media-heavy product will not be linear, and Supabase's $0.09/GB beyond 250 GB deserves your own modeling if that is you.

How to actually use this

Find your regime. Mostly-idle side project or pre-launch: Neon by default. Steady small production app, happy inside included quotas: Supabase's flat fee is genuinely good value. Past 100k MAU on bundled auth: do the math before the bill does it for you.
Watch the crossovers, not the platforms. The first crossover arrives when your database stops sleeping; the second when your user count crosses the included-MAU line. Both are visible in your own metrics months before they hit the invoice.
Decide auth and database together. The single biggest line in this entire analysis is an auth meter on a database platform.

Every price in the model links to its source and was verified against both pricing pages in June 2026 (prices change; the repo holds the dated record). Like the benchmarks, the model is open source and contributions are welcome: if a price moved or an assumption looks wrong, open an issue or PR and we will rerun the curves. The live dashboard carries the measured performance data this series is built on, our full Neon vs Supabase comparison lays out the architecture and feature differences side by side, and part four will close the series with something nobody has benchmarked properly yet: what it costs in AI agent tokens to build the same application on each platform.