When we say "Ship faster with Postgres" — it's not just about helping you build and ship software faster. It's about helping you deliver that same feeling of faster to your customers.

Open Source Faster

See for yourself how faster gets shipped with these open source examples.

If you have an open-source demo that illustrates the capabilities of Neon, let us know here we'd love to feature it.

Faster in Production

Some of the incredible businesses delivering better experiences for their customers with Neon in the stack.

  • Retool – Manages 300K+ Postgres DBs with one engineer via Neon’s API. Details
  • Replit – SOTA Text to App Agent helping creators "build an app for that" in minutes, DB included. Details
  • White Widget – Scales up to 50M+ users in seconds with autoscaling. Details
  • Invenco – Handles high-traffic e-commerce spikes without needing to thinking about databases. Details
  • Branch Insurance – Builds on Serverless Postgres to deliver faster experience out-of-the-box. Details
  • Magic Circle – Handles 2M+ game sessions on Neon. Details
  • Cedalio – One-database-per-client model with auto-suspend. Details
  • BaseHub – Uses autoscaling to handle peak loads with zero manual tuning. Details
  • Create.xyz – Spins up Postgres backends instantly for AI-generated apps. Details
  • OpusFlow – DB-per-tenant delivers a fast, no-noisy-neighbor experience for energy customers. Details
  • 222 – Autoscales for heavy traffic surges without manual ops. Details
  • Recrowd – Scales up for crowdfunding spikes, down when idle. Details
  • BeatGig – Uses instant read replicas for fast analytics. Details
  • ketteQ – Runs hundreds of forecast simulations in parallel with instant branches. Details
  • Topo.io – AI GTM Platform outbuilds their competition with engineering grit and Neon. Details
  • Supergood.ai – High-throughput workload powering AI-generated API's for any site. Details
  • Shepherd – CI/CD test DBs spin up instantly via GitHub Actions. Details

Is your company using Neon to ship faster experiences faster? Let us know in this GitHub Discussion and we'll add you to the list!

Faster Features

Great software isn’t just functional—it’s fast. At Neon, it’s something we refine and build into our service in countless small ways. Here are some of the faster features we’re particularly proud of.

  • Faster Provisioning - Get a ready-to-use Postgres database in less than a second. Try it right here. 👇
    postgresql://neondb_owner:v9wpX3xjEnKT@ep-misty-sound-a5169vmg.us-east-2.aws.neon.tech/neondb?sslmode=require
  • Faster Branching - Our custom storage engine enables data + schema clones for databases of any size in less than a second. Try it in a web demo View Source
  • Faster recovery - The same storage engine lets you restore a 1TB DB in seconds Demo video
  • Faster autoscaling - Our Postgres autoscaling algorithm checks memory usage 10 times/second and VM metrics every 5 seconds to provision exactly the right compute to serve your workload. How we do it.
  • Faster serverless connections - We built an open-source HTTP proxy to reduce the number of roundtrips required to establish a database connection from 8 to 4. Read how
  • Faster cold starts - We reduced Postgres cold start times to ~500ms. Read How
  • Faster secure auth - We reduced CPU time of authenticating connections without compromising security. Read How
  • Faster Analytics - The pg_mooncake team wrote an analytical extension for Postgres that runs on Neon and got top ten on clickbench. Read how

You can read about the architectural decisions for Neon and even see all of our engineering RFCs, too. If you're interested we're hiring.

Try it yourself

Don't take our word for it. The best way to understand the performance of a service is to try it yourself. We've made Neon as easy as possible to try with a generous free plan with no credit card required.

Try Postgres on Neon

Neon is Serverless Postgres built for the cloud. Sign up for a free account to get started.

Sign Up

Check Open Source Benchmarks

Test faster yourself with these open-source third-party benchmarks, in addition to Neon's open source latency benchmark application:

If you have an open-source benchmark that includes Neon let us know here we'd love to feature it on this page. See also our guide on obtaining meaningful latency data in serverless database environments.

How to ship faster

Shipping faster UX is a full-stack job. For databases, your real-world speed depends primarily on three things:

  1. Connection Approach: Long-lived connections or a connection for every query?
  2. Client-Database Proximity: How close is your application (the client) to the database?
  3. Database Processing Time: How much time is the database spending answering each query?

You can visualize the way each factor contributes like this:

End-to-End Database Query Latency Factors
10ms is typical of DB in nearby region
0msTotal Latency: 91.0ms
Connection Time: 80.0ms
Query Time: 5.0ms
Postgres Processing Time: 1.0ms
Response Time: 5.0ms

What about cold starts? Databases on Neon can scale to zero when there are no active queries for a certain amount of time. We kept this topic separate below in Cold Starts because across the more than one million active databases on our platform, they occur very seldomly — there are fewer than 5 cold starts per second. Cold starts don't factor in to your real-world experience often enough to become an important consideration. For use cases where cold starts must be avoided, you can disable scale-to-zero with a single click. This option is available starting with our Launch plan.

Establishing a connection

Before you get any data from the database, you need to connect to it. This process of establishing the network connection and verifying the credentials on both sides traditionally takes several back and forth trips between application and database.

Standard Postgres TCP connections require nine roundtrips: Nine round-trips to get a result on a standard TCP connection to Postgres

When you combine nine round trips with any sort of network latency you get a 9x compounding effect on latency. How often you must establish a database connection depends on how you architect your app:

Long-Running Connections

Containerized and serverful applications all follow a pattern of establishing one or more long-running connections when the service first starts and keeping them alive until the service is restarted. This makes the connection time a non-factor in the user-facing experience of your application.

Short-Lived Connections

Serverless functions may be executing independently in short-lived environments, it’s not feasible to have a long-running connection. Every independent execution of a function must establish a connection to the database.

Tips for Serverless Connections

  1. Execute functions in a region that is the same or close to your database
  2. Execute multiple queries in a single function - so you only pay the connection tax once.
  3. Use an HTTP API via the Neon Serverless Driver - To reduce the number of roundtrips required to establish the connection. Serverless driver round-trips Neon's serverless driver and proxy have been optimized to reduce the number of roundtrips to the absolute minimum. To read more about how this works, see: Quicker serverless Postgres connections

Putting app and database close together

Client-database proximity plays a major role in real-world database latency. Here are the different scenarios laid out from lowest to highest latency.

ArchitectureRoundtripConnectOn Neon
Same Machine
When you put your database and your app on the exact same machine, latency is measured in microseconds.		>1ms~1msNot applicable
Same Region
Place the client (App) and Database in the same datacenter and region for lowest-possible latency.		~1ms~3msSame Region for Client and DB, see Private Link for VPC
Different Region
When client and database are in different regions, your latency varies based on geographic proximity.		Varies4x-8x RoundtripDifferent/varying Region for Client and DB

Minimizing database time spent answering the query

As your business (and database) grows, connection and network transit latency remain static and database processing time becomes the most important factor to optimize. Here are some pointers:

  1. Use connection pooling and autoscaling – Use the built-in connection pooler to handle many client connections efficiently, and enable Neon’s autoscaling so the database can allocate sufficient RAM/CPU on demand.
  2. Profile slow queries – Identify which SQL statements are slow or resource-intensive by starting with the Query History View in Neon. Neon query history tab The Query History tab shows total calls, avg time, and total time of each query. You can dig deeper with pg_stat_statements
  3. Add indexes on high-impact columns – Create indexes on columns that are frequently used in WHERE filters, JOIN conditions, or ORDER BY clauses to avoid full table scans. An index lets Postgres perform an index scan instead of a slower sequential scan, dramatically reducing query execution time.
  4. Reduce table and index bloat – Reclaim wasted space and improve performance by eliminating bloat (accumulated dead rows) in tables and indexes. Schedule regular maintenance like VACUUM to remove dead tuples and use REINDEX on bloated indexes. You can also fine-tune autovacuum settings to keep bloat in check over time.
  5. Leverage caching for reads – Ensure frequently accessed data is served from memory instead of disk. Neon’s architecture extends Postgres’s shared memory buffers with a local file system cache, so aim for a high cache hit ratio. You can monitor the Local file cache hit rate chart on the Monitoring page in the Neon Console to see how often data is read from cache versus storage and adjust your workload or memory allocation if needed.

Further reading – See PostgreSQL query performance guide for in-depth explanations and tips.

Definitions

To move fast, we must have a shared understanding of concepts and terms. Let's define some of the most commonly misinterpreted terms around how Neon works.

Serverless

To us, serverless means:

  • Instant Provisioning
  • No server management
  • Autoscaling
  • Usage-based pricing
  • Built-in availability and fault tolerance
It does NOT mean:
  • Pay-per-query
  • New computes (and cold starts) for every connection/query

For a full write-up, read the full Serverless Docs

Scale to zero

When a Neon compute endpoint hasn't received any connections for a specified amount of time, it can scale to zero. This is useful for:

  • Resource Management - Turning off unused databases is automatic.
  • Cost-Efficiency - Never pay for compute that's not serving queries.

But scale to zero is only useful if compute can start up quickly again when it's needed. That's why cold start times are so important.

Cold Starts

A cold start in Neon begins when a database project with a suspended compute endpoint receives a connection. Neon starts the database compute, processes the query, and serves the response. The compute stays active as long as there are active connections.

Applications of scale to zero

Look at the cold start times documented above and decide: In what scenarios is the occasional 500ms of additional latency acceptable?

The answer depends on the specifics of your project. Here are some example scenarios where scale to zero may be useful:

  • Non-Production Databases - Development, preview, staging, test databases.
  • Internal Apps - If the userbase for your app is a limited number of employees, the db is likely idle more than active.
  • Database-per-user Architectures - Instead of having a single database for all users, if you have a separate database for each user, the activity level of any one database may be low enough that scale to zero results in significant cost reduction.
  • Small Projects - For small projects, configuring the production database to scale to zero can make it more cost-efficient without major impact to UX.

Ready to Ship Faster?

The best way to understand the speed and flexibility of Neon is to try it yourself. With instant provisioning, branching, and autoscaling, Neon helps you build and ship faster experiences—without managing infrastructure.

Sign up for free today—no credit card required—and see how Neon can accelerate your workflow.

Try Postgres on Neon

Neon is Serverless Postgres built for the cloud. Get started in seconds with our free plan.

Sign Up