Fly.io Managed Postgres vs Neon: networking model, latency, and operational tradeoffs

Most teams comparing Fly Postgres and Neon aren’t really asking “which Postgres is better?” They’re asking: how does the networking model work, what does it mean for latency, and where are the operational sharp edges? This guide breaks that down in plain terms, focusing on real-world behavior rather than cloud brochure-speak.

Quick Answer: Fly Postgres is an unmanaged Postgres cluster running as Fly Machines inside your own private network; Neon is a managed, decoupled storage/compute Postgres service you reach over the public Internet. Fly Postgres wins when you want app and database in the same region and network with predictable low latency and full control; Neon wins when you want a fully managed database with autoscaling compute and don’t mind a “database as a remote service” hop.

The Quick Overview

• What It Is:

  • Fly Postgres (unmanaged): A Fly app that runs Postgres directly on Fly Machines, with flyctl sugar for bootstrapping clusters (replication, failover, snapshots, metrics). Conceptually: your own Postgres cluster, but pre-wired to fit Fly’s global network.
  • Neon: A multi-tenant, fully managed Postgres service with separated storage and compute, autoscaling, branching, and a hosted control plane.

• Who It Is For:

  • Fly Postgres: Teams comfortable owning Postgres operationally who want database and application to live in the same private network, on the same global fabric, with predictable latency.
  • Neon: Teams who’d rather offload database operations (upgrades, HA, backups) to a provider and are fine treating the DB as a remote SaaS dependency.

• Core Problem Solved:

  • Fly Postgres: “I want fast, colocated Postgres where my Fly apps run, without building my own images and orchestration from scratch.”
  • Neon: “I want Postgres that feels serverless—autoscaling compute, instant branches, and minimal DBA work—even if it lives outside my app’s network.”

How It Works

At a high level, the difference is where Postgres runs and how traffic reaches it:

• With Fly Postgres, your database is just another Fly app:

  • It runs as Fly Machines inside your Fly organization.
  • It sits on Fly’s Anycast-backed private network with WireGuard-based security.
  • Your app talks to Postgres over private IP, usually within the same region and rack switch if you choose your regions wisely.

• With Neon, your app talks over the public Internet to a managed control plane:

  • Neon’s storage and compute are decoupled and multi-tenant.
  • You connect via TLS over a standard Postgres endpoint (psql, drivers, etc.).
  • For Fly-hosted apps, that’s effectively “database as an external SaaS,” subject to public network routing and cross-provider distance.

Think in phases:

1. Network Path & Topology:

   • Fly Postgres:
     • App ➜ Fly Proxy ➜ Fly private network ➜ Postgres Machines.
     • In many setups, the Postgres app and your app share a Fly private network; traffic stays “inside the house.”
   • Neon:
     • App ➜ Fly Proxy egress ➜ Internet ➜ Neon endpoint (region) ➜ Neon’s storage/compute.

2. Latency & Placement:

   • Fly Postgres:
     • You pick regions (iad, lhr, syd, etc.) for both app and DB.
     • When they match, round-trips are often a few milliseconds because they share the same physical data center and private network fabric.
   • Neon:
     • Neon exposes regions of its own; you align Fly regions as closely as possible (e.g., iad to a US-East Neon region).
     • There’s always at least one external hop and cross-provider routing.

3. Operations & Failure Modes:

   • Fly Postgres:
     • You own Postgres: tuning, version upgrades, schema migrations, and “what happens when autovacuum falls behind” are yours.
     • flyctl gives you bootstrap and cluster management, plus replication and snapshots baked in.
   • Neon:
     • Neon owns most of that: managed HA, backups, scaling, and storage durability.
     • You trade off some control and locality for simplicity and a more “serverless” DB feel.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Colocated Machines (Fly Postgres)	Runs Postgres as Fly Machines in the same regions and private network as your app.	Sub-10ms DB round-trips when you colocate; simple, predictable network behavior.
Managed Control Plane (Neon)	Provides fully managed Postgres with decoupled storage/compute and autoscaling.	Offloads DB operations and scaling; you focus on application logic.
Private Networking vs Public Egress	Fly Postgres uses WireGuard-backed private networking; Neon is reached via TLS over public Internet.	Choose between in-cluster, low-latency traffic (Fly) and external SaaS connectivity with easier DB administration (Neon).

Fly Postgres networking model

Fly Postgres is “just” a Fly app, but with extra tooling:

• Fly Machines: Each Postgres node runs in a Machine with local NVMe storage.
• Private networking:
  • Machines get private IPv6/IPv4 addresses in your Fly org’s network.
  • App ↔ Postgres traffic can stay completely private; no public IP required.
• Anycast + region placement:
  • For client traffic, Fly Proxy routes users to the nearest region.
  • Inside your org, you explicitly choose regions for the Postgres Machines—HA presets are typically 3-node clusters spread across regions or AZ-like groups.

Network flow when app and DB are colocated:

1. User hits app.example.com.
2. Fly Proxy routes the HTTP request to your app Machine in, say, iad.
3. Your app connects to Postgres at a private address (e.g. fdaa:0:1234::2) over the Fly private network.
4. The Postgres Machine lives in the same iad region. The hop is essentially “across the rack.”

Result in practice: very low and stable DB latency, especially for chatty ORMs or workloads with many small queries.

Fly Postgres also supports:

• Replication and failover: High availability configs are three-node clusters, with automatic failover and daily snapshots.
• Metrics and monitoring: Shipping basic metrics so you’re not flying blind.
• Open-source app definition: The cluster is built from a public app (fly-apps/postgres-flex), so you can fork and customize. Caveat: once you fork, fly postgres commands no longer manage that app.

Neon networking model

Neon’s model is different:

• Postgres over the Internet: Your app connects via TLS to a Neon endpoint (hostname + port), like any other managed database.
• Decoupled storage & compute:
  • Storage is a log-structured system that can be snapshotted and branched.
  • Compute nodes spin up/shut down on demand, sometimes incurring warmup latency.
• Regions:
  • Neon runs in a set of cloud/provider regions. You pick one; then you try to place your Fly app in a nearby region for better latency.

Typical flow for a Fly app using Neon:

1. User hits your app on Fly in cdg (Paris) or lhr (London).
2. Fly Proxy routes them to the nearest Fly app Machine.
3. Your app opens a TLS connection to a Neon endpoint in, say, eu-west.
4. Traffic leaves Fly’s network, rides the public Internet, and hits Neon.

The main implications:

• You’re subject to cross-cloud routing, middleboxes, and Internet weather.
• You don’t get intra-org private connectivity; it’s just a secure external DB.
• Latency is still usually acceptable if regions are close, but it’s inherently less predictable than “private network in same DC.”

Latency comparison: Fly Postgres vs Neon on Fly

Here’s the practical latency story, assuming your app runs on Fly:

When Fly Postgres wins

• Colocated region setup:
  App in iad, Postgres in iad. Most queries are single-digit ms round-trips. Your ORM can be chatty without punishing users (within reason).
• Global apps with regional DBs:
  You can deploy multiple Postgres clusters (or read replicas) in different regions and steer app traffic regionally. Users in Sydney talk to a DB in syd, not transatlantic.

Why it’s fast:

• No public Internet.
• Fewer middle hops.
• NVMe-backed storage as close as it gets to your app.

When Neon is “fast enough”

• Single-region SaaS apps:
  If your Fly app sits near Neon’s region, app↔DB latency might sit in the ~10–25ms range. That’s fine for many CRUD workloads.
• Burst workloads with idle periods:
  Neon can spin down compute; first query might pay a cold-start penalty, but subsequent queries are typical DB RTT over the Internet.

Where Neon can suffer:

• Very chatty workloads (hundreds of small queries per request).
• Cross-continent gaps (Fly app in syd, Neon in a US region).
• Latency-sensitive paths (auth, session lookups) on every request.

Operational tradeoffs

Fly Postgres: control, locality, and responsibility

You get:

• Full control of Postgres: Extensions, config, tuning, postgres.conf, replication topology.
• Integrated with Fly primitives:
  • Machines you can SSH into for debugging.
  • NVMe + object storage (e.g., Tigris) for data patterns that need both fast local disk and durable global storage.
• Predictable scale patterns: You scale by provisioning more/larger Machines, adding replicas, or sharding at the app layer.

You also own:

• Backups and disaster recovery strategy:
  Fly Postgres comes with daily snapshots and replication, but you design RPO/RTO and test restores.
• Major version upgrades and migrations:
  You plan the dance steps. Fly gives you the floor, not the choreography.
• Capacity planning:
  Overcommit NVMe or CPU, and you’ll feel it. Underprovision, and latency will climb before someone pages you.

It’s explicitly not a fully managed database service. Think “Postgres on a very convenient global substrate” rather than “click and forget.”

Neon: outsourced DB operations, external dependency

You get:

• Managed Postgres lifecycle: Neon handles patching, minor upgrades, backups, HA.
• “Serverless DB” vibes:
  • Compute autoscaling.
  • Branching databases for staging, preview environments, and testing.
• Reduced ops surface area: Your team does less “DBA at 2 a.m.”

You trade:

• Less locality and network control: You can get close to Neon, but you can’t bring it into your Fly private network.
• Dependency on another control plane:
  If Neon’s control plane or region has issues, your app feels it immediately.
• Less flexibility at the VM level: You’re not choosing the underlying storage media, tuning kernel params, or customizing the base image.

Ideal use cases

• Best for low-latency, Fly-native apps (Fly Postgres):
  Because it keeps your database in the same private network and regions as your app, minimizing query RTT and avoiding public egress. You get sharp, predictable performance for global apps, microservices, and anything that hates network variance (real-time APIs, AI inference services logging high-frequency events).

• Best for teams that don’t want to run Postgres at all (Neon):
  Because Neon offloads most operational work—backups, HA, scaling—while still speaking standard Postgres. Great for early-stage products, teams without in-house DB expertise, and workloads where “good enough latency” beats “owning more infra.”

Limitations & considerations

• Fly Postgres limitations:

  • Not a fully managed service: You are the DBA. If you want a “just give me Postgres and never make me think about it” experience, you may be disappointed.
  • Operational complexity scales with ambition: Multi-region, cross-cluster setups are powerful but also more complex. You need to design for failover, consistency, and migrations intentionally.

• Neon limitations (when paired with Fly):

  • Network is external: You can’t erase the extra Internet hop. Latency and variance will always be higher than a local Machine talking to a local NVMe-backed database.
  • Cold starts & autoscaling behavior: Serverless compute can introduce first-request latency and behavior you need to model for heavy, spiky workloads.

Pricing & plans

Exact numbers change, so think in models, not cents.

• Fly Postgres cost model:

  • You pay for Machines (CPU/RAM), NVMe volumes, and network egress (if leaving Fly).
  • Because you’re billed down to the second on Machines, you can right-size clusters and scale them as your app grows.
  • Backups and replication are done with Fly primitives (snapshots, extra Machines).

• Neon cost model:

  • You pay for storage and compute (often in a serverless/usage-based model).
  • Autoscaling can be cost-efficient for spiky or low-duty-cycle workloads, especially early on.
  • Treat it like another SaaS: easy to start, but with its own bill and rate limits to track.

In practice, for a high-throughput production system, Fly Postgres can be more cost-predictable because you control Machines directly. Neon may be cheaper and simpler for small teams or workloads where the database isn’t the primary bottleneck.

• “Own the DB, own the performance” (Fly Postgres):
  Best for teams needing predictable performance, tight integration with Fly networking and storage, and willing to wear the DBA hat at least part-time.

• “Outsource the ops, accept the hop” (Neon):
  Best for teams who want database as a service and can live with the extra network distance and control-plane dependency.

Frequently Asked Questions

Can I run Fly Postgres and Neon together in the same architecture?

Short Answer: Yes. Many teams use Fly Postgres for latency-critical paths and Neon for managed analytics, staging, or branching.

Details:
A common pattern looks like:

• Primary transactional DB on Fly Postgres, colocated with app Machines for low latency.
• Neon used as:
  • A branchable staging environment fed by sanitized production data.
  • A read-only analytics replica (via streaming or periodic ETL).
  • A sandbox per feature branch for developer testing.

Because both speak standard Postgres, you can use tools like pg_dump, logical replication, or CDC pipelines to sync data in one direction. The key is treating Neon as an external service in your network diagram: separate connection strings, separate failure modes, and explicit retry/timeouts.

How do I decide between Fly Postgres and Neon for a new Fly.io project?

Short Answer: If latency and network control matter, start with Fly Postgres. If ops simplicity matters more than locality, start with Neon.

Details:
Use this rough decision tree:

• Are you building on Fly as your primary runtime?

  • Yes:
    • Do you care about keeping DB latency under ~10ms and inside your private network?
      • Yes: Start with Fly Postgres.
      • No / not sure: Neon is viable; weigh ops vs latency.
  • No:
    • If your app already lives elsewhere, Neon may fit more naturally as a standard managed DB.

• Do you have someone who can be “part-time DBA”?

  • Yes: You’ll likely get better performance and control from Fly Postgres.
  • No: Neon lets you avoid a lot of DB plumbing.

Remember you’re not locked in forever. It’s Postgres either way. But moving data and expectations later is always more painful than choosing the right tradeoffs upfront.

Summary

The real difference between Fly Postgres and Neon isn’t “which one is more Postgres.” It’s where your database lives relative to your app, how packets reach it, and who signs up to push the boulder of operations uphill.

• Fly Postgres embeds your database into Fly’s own fabric: Machines, private networking, NVMe, and global routing. You get low-latency, colocated access and full control, in exchange for owning HA, upgrades, and tuning.
• Neon runs Postgres as an external, managed service you reach over the Internet. You trade some locality and network predictability for autoscaling, branching, and outsourced DBA work.

If your gut reaction is “my API should respond in under 100ms from anywhere and I’m okay thinking about regions,” Fly Postgres is the better default. If your reaction is “please, I just want a database that someone else cares for,” Neon is a legitimate choice—just budget in the network hop.

Next Step

Get Started(https://sprites.dev/)