What Is Neon Postgres and Why SpeedMVPs Uses It
Neon is a cloud PostgreSQL service built on a custom storage architecture that separates compute from storage. Compute (the Postgres process) can scale to zero when there is no active traffic, billing stops, and it restarts within a few hundred milliseconds when a new query arrives. Storage is persistent and separate from compute, so data survives compute scale-to-zero events. The database branching feature is Neon's most distinctive capability. A branch is a copy-on-write clone of the database at a specific point in time. Creating a branch takes seconds regardless of database size (because Neon's storage architecture uses branching natively). You can create a branch for each development environment, each pull request, or each test run, and discard it when done. Branches share underlying data pages that have not been modified, so they consume minimal additional storage. SpeedMVPs chooses Neon over Supabase for AI MVPs in situations where the founder is bootstrapped and idle database costs matter (scale-to-zero eliminates idle cost), where the CI/CD pipeline benefits from per-PR database branches (each pull request gets its own isolated Postgres with the current schema applied), or where the product does not need Supabase's built-in auth and storage features that would be unused. Neon and Supabase both support pgvector - the vector search capability is equivalent between them. The choice is about the surrounding feature set and pricing model.
Setting Up Neon Postgres in a Production AI Project
Neon setup is fast because of its managed nature. Here is the configuration SpeedMVPs applies for production AI projects. First, create a Neon project and select the appropriate region. Neon offers AWS us-east-1, us-west-2, eu-central-1, and ap-southeast-1 regions. For UK GDPR compliance, eu-central-1 (Frankfurt) is the current EU option. Neon does not yet offer an AWS eu-west-2 (London) region - if UK-only data residency is a strict requirement, assess whether eu-central-1 satisfies your GDPR data transfer obligations given the UK-EU adequacy decision. For most UK AI products, eu-central-1 is sufficient. Second, enable pgvector on the database. In the Neon console SQL editor: CREATE EXTENSION IF NOT EXISTS vector. pgvector is pre-installed on Neon - no additional configuration is required. Third, configure connection strings. Neon provides two connection string types: a direct connection (for long-running applications with persistent connections) and a pooled connection (via Neon's built-in PgBouncer, for serverless applications with many short-lived connections). For Next.js API routes and Vercel serverless functions, always use the pooled connection string. Using the direct connection from serverless functions exhausts Postgres connection limits under any meaningful load. Fourth, set up database migrations. Neon branches make migration workflows clean: run migrations on the main branch to update the production schema, and create a new branch from main for each development cycle so development always starts from the current production schema. Fifth, integrate with your ORM or query builder. Neon works with Drizzle, Prisma, and any Node.js Postgres client (pg, postgres.js). Use the pooled connection string for serverless contexts. For Drizzle, configure the drizzle-orm/neon-serverless adapter which handles Neon's WebSocket-based connection protocol, required for the serverless context. Sixth, configure autoscaling for the production compute. Neon's autoscaling adjusts compute units (CUs) between a minimum and maximum you define. Set the minimum to 0.25 CU for scale-to-zero on the free or Launch plans, and the maximum to match your peak load estimate. Monitor the autoscaling dashboard during load testing to confirm the maximum is set appropriately.
Key Features and Capabilities
Scale-to-zero is the feature that makes Neon economical for early-stage AI products. When no queries are running, the Neon compute instance suspends and billing stops. For an AI MVP in the validation phase with occasional traffic, this means the database costs essentially nothing during quiet periods. Cold start latency (the time for the compute to wake up after suspension) is typically 500 milliseconds to 2 seconds for the first query after an idle period. For most AI products, this is acceptable. For products where the first request latency must be sub-second, configure a minimum compute of 0.25 CU to keep the database warm at low cost. Database branching transforms the development workflow for AI products. Create a branch from main (production) for each feature or pull request. Apply and test schema migrations on the branch without risk to production data. Discard the branch when the PR is merged. For AI products where schema migrations include adding vector columns or HNSW indexes, testing migrations on a branch before production deployment prevents outages from index builds on large tables. Neon's storage architecture supports time-travel queries: you can connect to the database at any point in the last 7 days (or 30 days on paid plans) by setting a time offset on a branch. For AI products where debugging a data issue requires examining historical state, this is a useful debugging capability that requires no backup restore. pgvector on Neon behaves identically to pgvector on any other Postgres instance. HNSW indexes, cosine similarity queries, and hybrid search queries all work as documented. Neon's autoscaling handles increased memory requirements during HNSW index builds by scaling up compute units temporarily. Neon integrates with Vercel's integration marketplace, allowing automatic creation of Neon database branches for each Vercel preview deployment. This gives every pull request both a preview deployment of the application and an isolated database branch, enabling complete end-to-end testing without affecting the main database.
Real-World Workflow: Neon Postgres in an AI MVP
An example from SpeedMVPs: an AI newsletter summarisation tool for an independent UK media publisher. Users submitted their email inboxes via OAuth, and the tool generated daily briefings summarising articles across their subscriptions. The product needed a Postgres database for user data, subscription management, and newsletter content, with pgvector for semantic deduplication of similar articles across different newsletter sources. Neon was chosen over Supabase because the product did not use Supabase auth (the team used Clerk), Supabase Storage was not needed (content was fetched and discarded), and the bootstrapped founder was sensitive to idle database costs during the pre-launch period. The database schema included a newsletters table, a subscribers table, a content table (storing article content and embeddings), and a daily_briefings table. pgvector on the content table enabled semantic deduplication: before including an article in a briefing, a similarity search against articles already included in that day's briefing checked whether a semantically similar article was already present. The Neon Vercel integration created a database branch for each pull request. The CI workflow applied the current Drizzle migration stack to the branch and ran a seed script with anonymised test data. End-to-end tests ran against this branch, and the branch was deleted on PR merge. This meant the production database schema was always tested before deployment. At launch, with minimal traffic, the Neon compute spent most of each day suspended. The database cost in the first month was under USD 5. As the product grew, compute autoscaling handled the increased load without any configuration changes.
Cost and Pricing Considerations
Neon's free plan offers one project, 10 GB storage, 191 compute-hour hours per month (approximately 8 hours of continuous uptime at 1 CU), and basic branching. This is sufficient for development and very early validation but will exhaust during a production launch with any meaningful traffic. The Launch plan at USD 19 per month increases storage to 10 GB, compute-hours to 300 per month, and adds the Vercel integration for automatic preview branches. The Scale plan at USD 69 per month increases storage to 50 GB and compute-hours to 750, appropriate for production AI products with moderate traffic. Compute cost on paid plans is per compute-unit-hour consumed. With scale-to-zero, you only pay when queries are running. A product with 100 active users per day generating 10 database queries each requires roughly 2 to 5 minutes of compute per user, amounting to approximately 4 to 8 compute-hours per day at 0.5 CU - well within the 300 hours per month included in the Launch plan. pgvector HNSW index memory requirements drive compute unit selection. A table with 100,000 vectors needs approximately 600 MB of RAM for the HNSW index. Neon provides 1 GB RAM per CU, so a 1 CU instance handles 100,000 to 150,000 vectors comfortably. For larger datasets, configure a higher minimum compute to prevent the HNSW index from being evicted from memory on scale-to-zero events. Compared to Supabase Pro at USD 25 per month (with always-on compute), Neon's Launch plan at USD 19 per month with scale-to-zero is typically cheaper for early-stage products with irregular traffic patterns.
Alternatives to Neon Postgres
Supabase is the most direct alternative and the more feature-rich option. Supabase adds row-level security, built-in auth (with magic links, OAuth, and MFA), real-time subscriptions via PostgreSQL LISTEN/NOTIFY, edge functions, and object storage, all as integrated features on top of PostgreSQL. For AI MVPs that need these features, Supabase provides them in a single platform. SpeedMVPs chooses between Neon and Supabase based on which feature set matches the product requirements. PlanetScale is a MySQL-based serverless database with similar scale-to-zero and branching features. It does not support pgvector, making it unsuitable for AI products that need vector search within the database layer. Useful for non-AI SaaS products or for the application data layer in an AI product that uses a separate vector store. AWS RDS or Google Cloud SQL provide managed PostgreSQL with enterprise SLAs, compliance certifications (including NHS DSP Toolkit alignment), and deep cloud ecosystem integration. For regulated AI products requiring formal cloud compliance certifications, a hyperscaler managed Postgres is the appropriate choice over Neon. The tradeoff is significantly higher cost, no scale-to-zero, and more complex setup. Fly.io Postgres is a self-managed PostgreSQL deployment on Fly's global infrastructure. It requires more operational knowledge than Neon but provides geographic distribution close to users. For latency-sensitive AI products where database proximity matters, Fly Postgres is worth evaluating.