Fly.io Managed Postgres plans: Basic vs Starter—what should I pick for a new production app?

If you’re about to launch a new production app on Fly.io and you’ve hit the “Managed Postgres: Basic or Starter?” fork in the road, you’re in the right place. This guide walks through how the plans differ, what actually matters in production, and a couple of simple rules of thumb so you don’t overthink it.

Quick Answer: For a new production app with real users but modest load, start with Managed Postgres Starter for predictable performance and fewer surprises. Use Basic for prototypes, tiny internal tools, or cost-sensitive side projects where occasional contention or slower queries are acceptable.

The Quick Overview

• What It Is: Fly.io Managed Postgres is a managed Postgres service built on Fly Machines, giving you production-grade PostgreSQL with backups, HA options, and Fly-native networking without running your own database app.
• Who It Is For: Developers who want real Postgres in production but don’t want to hand-roll backups, failover, and multi-region networking—or babysit VMs at 3 a.m.
• Core Problem Solved: It removes the “do I really want to operate a database cluster myself?” concern, while still behaving like normal Postgres your app and tools already understand.

How It Works

Managed Postgres runs as Fly Machines under the hood, wired into Fly’s private networking, storage, and operational tooling. You talk to it like ordinary Postgres; Fly handles the scaffolding.

At a high level:

1. Provision: You create a Managed Postgres cluster with fly postgres create, pick a plan (Basic or Starter), region, and optionally an HA topology.
2. Connect: Fly generates credentials, puts the database inside your Fly private network, and your app connects over an internal address with TLS.
3. Operate: Fly handles snapshots, metrics, and failover (if you chose HA). You scale up/down instances and storage as your app grows.

Both Basic and Starter share those mechanics. The differences are in sizing, performance expectations, and how much headroom you get before you hit pain.

Basic vs Starter: What Actually Changes?

Fly’s public docs frame “Fly Postgres (unmanaged)” as an app you operate yourself. Managed Postgres sits above that: the platform runs and maintains the cluster for you.

Within Managed Postgres, plan tiers essentially decide:

• Resource profile (CPU, RAM, disk baseline)
• Performance expectations (throughput, latency variance)
• Operational headroom (how far you can push before you need to resize)
• Price point (how much you’re comfortable spending on Day 1)

There’s no API-level difference in the Postgres you talk to. Both plans:

• Expose standard PostgreSQL (psql, ORMs, migrations all behave normally)
• Run inside your Fly private network
• Support HA configurations (multi-node clusters)
• Include the usual operational glue: metrics, monitoring, snapshots

The question is not “Can I run production on Basic?” but “How much risk and tuning am I willing to accept at my traffic level?”

How It Works (Plan-Level)

Here’s how to think about the two plans from a practical workflow perspective.

1. Basic Plan: “It Works, Okay?” Tier

For small apps, prototypes, or predictable low-traffic workloads.

• You run fly postgres create, choose Basic, single region.
• You connect your app; everything works, and cost is minimal.
• As write volume and concurrent connections grow, you may start seeing:
  • Contesting connections
  • Longer query times during spikes
  • Need to be more careful with indexes and N+1s

You can still enable HA and snapshots; you’re just doing it on a more constrained resource profile.

Good mental model: A solid dev/staging tier that can also carry small production apps if you know your load and can tolerate occasional slower queries.

2. Starter Plan: “New Production App” Default

For serious new apps that you still expect to evolve.

• You run fly postgres create, choose Starter, likely HA (3-node) if this is user-facing production.
• You get more CPU/RAM and more consistent disk performance, so you have:
  • Headroom for ORM inefficiencies and early schema mistakes
  • Less sensitivity to brief spikes (launch announcements, marketing blasts)
  • Better baseline for background jobs, reporting queries, and API traffic sharing one cluster

You’re still not locking yourself into a vast cluster; you’re just opting into an environment that behaves like a real production database from day one.

Good mental model: Reasonably sized production Postgres that doesn’t require you to be perfect with queries on week one.

3. Moving Between Plans

Both plans ride on the same underlying platform model. As your app grows, you can:

• Scale up resources (larger Machines / storage)
• Move from Basic → Starter if you started tiny
• Evolve toward more complex topologies (read replicas, more regions)

Plan choice is not irreversible, but changing later under load always hurts more than picking a slightly safer option upfront.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Managed Backups & Snapshots	Automatically captures daily snapshots and retains them for restore.	Protects you from “oops” moments and hardware failures.
HA Cluster Options	Supports 3-node high-availability setups with automatic failover.	Keeps production alive when a node or region hiccups.
Fly-Native Networking	Places Postgres inside your Fly private network with end-to-end encryption.	Low-latency, private connections from your app to your DB.
Basic Plan Tier	Entry-level resource profile at lower cost.	Great for small workloads and budget-sensitive environments.
Starter Plan Tier	Larger resource profile with more predictable performance.	Safer baseline for new production apps and growing traffic.
Integration with Fly Apps	Works with flyctl, Fly Machines, and Fly Proxy out of the box.	One platform for app + database, simpler mental model.

Ideal Use Cases

• Best for Basic:

  • Small internal tools, admin dashboards, or hobby apps.
  • Early-stage MVPs where you’re validating product fit and costs matter more than latency.
  • Staging and QA environments that mirror production schema but don’t carry production traffic.
    Because it keeps cost low and still gives you “real Postgres” without much operational work.

• Best for Starter:

  • Brand-new production apps with paying users or external customers.
  • APIs where P95 latency matters, but you’re not yet a high-traffic SaaS giant.
  • Apps that mix transactional load with background jobs (email, billing, analytics rollups) on the same DB.
    Because it gives you more headroom and stability so you can focus on shipping features instead of tuning every query from day one.

Limitations & Considerations

• Not “infinite scale” magic:
  Managed Postgres is still a single Postgres cluster under the hood. Both Basic and Starter will hit limits if you run massive multi-tenant analytics workloads or let a single unbounded query chew CPU. If you’re planning serious scale, design with indexing, queuing, and caching from the start.

• HA doesn’t replace backups or testing failover:
  High availability protects you from node failures, not from bad migrations or application bugs. Keep an eye on snapshots, practice restoring them in non-prod, and understand how your app handles failover events.

• Plan choice won’t fix bad schema/query design:
  Starter’s extra headroom buys you time, not immunity. N+1 queries, missing indexes, and unbounded SELECT * will hurt on any tier; they just hurt sooner on Basic.

Pricing & Plans

Exact numbers live on Fly.io’s pricing page and can change, but structurally:

• Basic is the lower-cost tier.
  You’re trading some performance and headroom for a smaller bill. Perfect when every dollar matters or the database is not mission-critical.

• Starter is priced higher but still “sane for a new SaaS.”
  You’re paying for the extra CPU/RAM and more predictable disk performance that make production less surprising.

When in doubt:

• If this database will hold customer data and money flows through it, pick Starter.
• If it’s internal, experimental, or side-project grade, Basic is usually enough.

Example Positioning

• Basic Plan: Best for solo devs or small teams needing a reliable Postgres for low-traffic apps, internal tools, or staging, where occasional performance hiccups are acceptable.
• Starter Plan: Best for teams launching a new production app with external users, where you want predictable performance, room for growth, and fewer “why is Postgres on fire?” moments.

Frequently Asked Questions

Is the Basic plan safe for production?

Short Answer: Yes, for small, low-to-moderate traffic apps where performance isn’t mission-critical.

Details:
Basic is still Managed Postgres: you get backups, HA options, and proper Fly networking. Many production apps can live on Basic, especially early on. The main tradeoffs are less CPU/RAM and tighter performance budgets, so you’re more sensitive to spikes, heavy background jobs, or expensive queries. If you’re building something with real user expectations (SaaS dashboard, customer-facing app), it’s often more pragmatic to start on Starter so you’re not forced into a mid-incident resize later.

Can I switch from Basic to Starter later?

Short Answer: Yes, but it’s smoother if you plan for it before you’re at the edge.

Details:
Because plans share the same core platform, you can adjust resources and move up a tier as your workload grows. That said, resizing a busy production database always takes planning: you need to think about connection drains, migration windows, and failover behavior. The less headroom you have when you decide to move, the more careful you need to be. If you already know you’re aiming for a real production launch in the next few weeks, starting on Starter is usually the lower-stress path.

Summary

For a brand-new production app on Fly.io, Managed Postgres Starter is the default choice: more CPU and memory, steadier performance, and enough space to survive early schema mistakes and traffic spikes without living in EXPLAIN ANALYZE.

Use Basic when:

• You’re cost-sensitive and traffic is modest and predictable.
• The app is non-critical (internal, experimental, or a side project).
• You’re comfortable with more performance tuning and watching metrics earlier.

Use Starter when:

• You’re launching something with real users and real expectations.
• You want fewer “database is the bottleneck” surprises in the first few months.
• You’d rather spend time on features than on squeezing every millisecond out of queries on day one.

You can grow and adjust as your app evolves, but it’s almost always cheaper—financially and emotionally—to start with enough headroom.

Next Step

Get Started