For years, “use PostgreSQL” was easy advice and hard reality. The database was brilliant—until you had to babysit migrations, scaling, replicas, backups, and connection limits while also building product. What’s changed is simple: Neon and Supabase have turned PostgreSQL from “the right choice” into “the obvious one” for indie hackers who want speed, branching, and guardrails without hiring a DBA.

The PostgreSQL problem indie hackers actually felt⌗

PostgreSQL isn’t the issue. Operations are. Even the most capable solo developer eventually runs into the same friction points:

  • Scaling pressure: PostgreSQL can scale, but you still need to think about indexing, connection pooling, and when to move off a single box.
  • Migrations with consequences: Schema changes are required, but they’re also risky. One bad migration can break production, and “rollback” is never as clean as you hope.
  • Environment sprawl: You want a staging database, a preview database for each PR, and maybe a couple of test fixtures—then the cost and overhead hit.
  • “Not just a database”: Modern apps require auth, storage, file uploads, background jobs, and real-time updates. Building all of that correctly is what keeps projects small—until you realize you’ve reinvented half a platform.

Firebase and PlanetScale filled part of that gap: they were easy to operate and packaged nicely. But they often moved developers away from SQL-first thinking, and the long-term cost was avoidable lock-in.

The new wave flips the story: keep PostgreSQL, remove the operational drag, and add the platform features you’d otherwise bolt on yourself.

Neon: serverless Postgres plus schema branching (git for your data model)⌗

Neon’s big idea is to make Postgres feel elastic without forcing you to become a cloud infrastructure expert. Instead of treating your database like a fixed-capacity server, Neon offers serverless scaling that’s designed to handle varying workloads.

But the feature indie teams care about most is branching.

Think about how you ship code today: you branch your app, test changes, and merge. For databases, the equivalent has historically been “migrate in place” (or maintain multiple manual environments). Neon’s branching brings a Git-like workflow to your schema and data access patterns, so you can test changes in isolation.

A practical example: preview environments for every change⌗

Imagine you’re building a SaaS dashboard and you want a URL where teammates can review the UI and the database schema changes behind it.

With branching, you can create a database branch tied to a specific code change, run migrations, seed test data, and point your preview deployment at that branch. If the change passes, you merge forward; if it fails, you discard the branch. No emergency migration surgery on shared environments.

Why this matters⌗

Branching isn’t just convenience—it’s risk management.

When you can safely test migrations in a disposable environment, you’ll ship faster. You’ll also write migrations differently. Instead of “make it work on production,” you start writing migrations like you’re testing code: deterministic, reviewable, and rollback-friendly.

Serverless scaling is the enabler; branching is the workflow upgrade.

Supabase: Postgres as the core, plus auth, storage, edge functions, and real-time⌗

If Neon is the “make Postgres easy to operate” story, Supabase is the “make your app stack coherent” story.

Supabase sits on Postgres, then adds the missing pieces that used to send indie hackers chasing a grab bag of services. The result is a platform that feels like Firebase in spirit—but keeps PostgreSQL at the center.

Key components include:

  • Authentication: sign-in flows you can configure quickly, plus a clean way to integrate user identity into your database-backed logic.
  • Storage: a practical pipeline for files and assets with policies you can reason about.
  • Edge functions: server-side logic close to users, useful for webhook handling, background orchestration, or lightweight APIs.
  • Real-time: the ability to react to database changes without inventing your own pub/sub layer.

A practical example: “events from the database” without extra plumbing⌗

Suppose your app needs to update a dashboard instantly when a user’s job status changes. With Supabase’s real-time capabilities, you can subscribe to updates backed by Postgres changes.

Instead of building a custom event stream (or managing another database for events), you keep your source of truth in Postgres and let the app react. It’s a tighter feedback loop: database changes produce product changes.

Edge functions as the glue⌗

Postgres is your model; edge functions handle the “app logic around the edges.” For example:

  • a Stripe webhook handler that validates the event, writes entitlements into Postgres, and triggers any downstream updates;
  • a function that processes an uploaded file, updates metadata in Postgres, and returns a clean response to the client.

You still get SQL where it counts—and you don’t have to build an entire backend platform yourself.

The killer combo: Neon for database ergonomics, Supabase for app infrastructure⌗

Here’s the opinionated take: use the tools where they’re strongest.

  • Neon brings excellent Postgres scaling and branching—the operational freedom and safe schema experimentation that keeps shipping moving.
  • Supabase brings the product layer: auth, storage, edge functions, and real-time so you’re not stitching together five services to launch a credible MVP.

Depending on your setup, you might choose one as your primary platform. But the larger point is that the PostgreSQL ecosystem has matured: you can keep your architecture SQL-first and still get the “batteries included” experience.

A realistic indie workflow⌗

  1. Build features with Postgres-backed tables.
  2. Use branching to test migrations and seed data safely for preview deployments.
  3. Use Supabase for authentication and file handling (so your app logic doesn’t balloon).
  4. Use edge functions for webhook glue and lightweight APIs.
  5. Use real-time subscriptions for “it updates instantly” UX.

This is how you compress the distance between idea and working product.

Generous free tiers change the economics of shipping⌗

Indie hackers don’t just need tools—they need room to experiment without learning the painful cost curve too early. Neon and Supabase both offer generous free tiers, which matters for two reasons:

  • You can build and iterate without turning every test into a budgeting exercise.
  • You can keep the architecture you want. When costs are predictable, you don’t feel forced into shortcuts like denormalizing everything prematurely or avoiding real-time features entirely.

The end result is cultural as much as financial: PostgreSQL stops being “what you’ll use later when you have money for ops,” and becomes what you start with on day one.

What to watch out for (so you don’t repeat old mistakes)⌗

Even with modern platforms, you can still shoot yourself in the foot. The goal isn’t magic—it’s fewer chores and better workflows. A few practical guardrails:

  • Treat migrations like code: review them, test them in a branch, and keep them deterministic.
  • Index intentionally: serverless and managed platforms don’t erase query design. If your dashboard needs fast filtering, add the right indexes early.
  • Be mindful of connection patterns: real-time and edge functions can increase concurrency. Use pooling strategies appropriate to your stack.
  • Keep security policies tight: Supabase’s strengths include a strong approach to access control—use it deliberately rather than “open by default.”

If you do these things, the new Postgres workflow becomes less about reacting to production fires and more about shipping.

Conclusion: Firebase’s default era is ending—SQL-first is back⌗

Neon and Supabase don’t just make PostgreSQL easier; they restore a long-lost indie developer feeling: you can build a serious backend without turning every day into infrastructure work.

Serverless scaling and schema branching mean safer, faster development. Auth, storage, edge functions, and real-time mean you don’t sacrifice product velocity to avoid complexity. And generous free tiers keep experimentation affordable.

PostgreSQL was always the right core. Now it’s the right developer experience too—and that’s the shift that finally makes “use Postgres” the default choice again.