Neon

Operator's take

If you've ever paid for a cloud Postgres instance that sat idle 80% of the time because you didn't want to deal with cold-start delays, Neon is the answer to that specific frustration. The platform separates storage from compute so that when nothing is hitting your database, compute stops billing (it scales to zero after roughly 5 minutes of inactivity, configurable on higher tiers). When traffic returns, it wakes back up. For side projects, staging environments, and apps with uneven traffic, that changes the economics meaningfully compared to a traditional always-on managed Postgres.

The feature that actually changes how you work day-to-day is database branching. Creating an isolated copy of your production database — full data, full schema — takes a button click or a CLI command. Each branch shares storage with its parent until it diverges, so you're not paying to duplicate 10GB of data every time a developer wants a safe sandbox. That makes testing schema migrations, running QA against real data, and giving each developer their own copy feel like a normal part of the workflow rather than a weekend infrastructure project.

Neon has been expanding beyond pure database into a backend platform — auth is now included across all plans (based on Better Auth, one-click install), and object storage, AI gateway, and a Functions/Compute layer are all in early access. The Databricks acquisition in May 2025 also points toward deeper data platform integration over time. That said, it's still primarily a Postgres layer: if you need a fully integrated BaaS today with real-time subscriptions or a polished low-code console, Supabase is further along. Neon wins when branching, cost-at-scale, and AI-agent database provisioning matter more than a bundled feature suite. The bigger risk is building on a platform mid-transition to Databricks' roadmap.

What it's good at

• Scale-to-zero billing — compute pauses when no queries are running and resumes on demand; you pay only for actual usage, not reserved capacity sitting idle.
• Database branching — instant isolated Postgres copies for testing, development, or CI; branches share storage with the parent until they diverge, so they're cheap to create.
• Point-in-time recovery — restore to any prior moment without managing backup scripts or snapshots; built in at the platform level.
• Multi-region deployment — place your database closer to users across regions to cut latency without spinning up your own infrastructure; check the current region list on the docs as the catalog is still expanding.
• Standard Postgres compatibility — connects via any standard Postgres client or connection string; integrates with Vercel, Netlify, and other platforms through native hooks.
• Generous free tier — the free plan includes 0.5 GB storage and 100 CU-hrs/month per project, up to 100 projects, with no credit card required and no time limit; genuinely useful for prototypes and low-traffic apps, not just a trial.
• Built-in auth — Neon Auth ships with every plan (up to 60K MAU on Free, 1M MAU on Launch and above), based on Better Auth with a one-click install, users and sessions stored in Postgres alongside your data.
• Agent-first API — databases provision via API in ~120ms with a connection string returned instantly; purpose-built for codegen and AI agent platforms deploying thousands of isolated databases.

What it's not

• Not a complete BaaS replacement today — Neon now includes auth and has object storage, AI gateway, and a Functions/Compute layer in early access, but real-time subscriptions and a polished low-code console are not part of the current surface; if you need a full-featured BaaS in one package, Supabase is further along.
• Not suited for zero-tolerance latency on cold starts — dormant instances take measurable time to wake on the first request after scale-to-zero; for SLAs requiring consistent sub-100ms response times on every query, keep compute always-on (configurable on higher tiers) rather than running scale-to-zero.
• Not a fit for PostgreSQL extension power users requiring superuser — the documented extension library covers common cases like pg_vector, PostGIS, and TimescaleDB, but extensions needing superuser privileges are the typical gap; check the current supported-extension list before migrating.
• Not yet globally distributed — region coverage is still expanding; if your users are concentrated in Asia-Pacific or LatAm, verify the current region list on the docs before committing, since the catalog has historically leaned toward North America and Europe.
• Roadmap now tied to Databricks — a Databricks company since May 2025; product direction will increasingly reflect Databricks' data platform priorities; low sunset risk but worth monitoring for operators building long-term on the free tier or who want a purely independent vendor.