Building Yaldi.chat: Why PostgreSQL on Neon Beat Supabase and Traditional RDS

Databases tend to lock in architectural decisions longer than almost anything else. Migrating a database—especially one that holds production data and enforces integrity—is a different level of commitment. For Yaldi, the database needed to be boring, durable, and flexible enough to survive growth without forcing early overcommitment. Yaldi has been running on Neon for over a year now and I've really fallen in love with that platform.

What Yaldi Needed From a Database

Before comparing vendors, I defined the requirements:

  • Strong relational guarantees (constraints, transactions, foreign keys)
  • Excellent concurrency behavior for many short-lived connections
  • Low idle cost (most requests are reads, and traffic is bursty)
  • Elastic scaling without manual resizing or high effort read replications
  • Clear operational boundaries—no surprise maintenance work
  • Compatibility with serverless compute

That list immediately ruled out several categories of databases and pushed the decision firmly toward PostgreSQL.

Why PostgreSQL

PostgreSQL is not the most fashionable choice, and that’s part of the appeal. Yaldi relies heavily on relational concepts: ownership, membership, moderation state, aliases, versions, and history. These are not key-value problems. They benefit from constraints, joins, and transactional updates.

PostgreSQL brings:

  • Strong ACID guarantees
  • Rich indexing options
  • Predictable query planning
  • A mature ecosystem
  • Excellent tooling and introspection

Crucially, PostgreSQL lets the database enforce correctness so the application doesn’t have to re-implement it everywhere.

Traditional RDS: Familiar, Powerful, and the Wrong Shape

The obvious default in AWS is Amazon RDS but I knew early on it wasn't in alignment with my cost targets. It’s reliable, well-understood, and works well for many workloads. It also has several characteristics that don’t align well with Yaldi’s architecture.

1) You pay for uptime, not usage

RDS charges for provisioned instances, whether they’re busy or idle. For a project with uneven traffic, this means paying for capacity you don’t consistently use.

2) Manual scaling decisions

Scaling RDS generally means choosing instance sizes, scheduling maintenance windows, and planning capacity in advance. That’s fine for predictable workloads. It’s less attractive for a system that might grow unevenly or unpredictably.

3) Connection management friction with serverless

Lambda functions create short-lived connections. RDS, by default, expects longer-lived connection pools. You can bridge that gap with connection proxies, but each additional component adds cost and operational complexity.

4) Operational gravity

Once you choose RDS, you’re signing up to think about backups, failover, storage growth, and patching—even if the service manages much of it for you. For Yaldi, the goal was to minimize “things to think about.”

Supabase: Powerful, Opinionated, and More Than Needed

Supabase is an impressive platform. It provides PostgreSQL plus authentication, storage, realtime subscriptions, and a tightly integrated developer experience. For Yaldi, that breadth was a drawback.

1) You’re buying a platform, not just a database

Supabase bundles many features that Yaldi already solves differently: auth flows, media storage, and API access patterns. Paying for and mentally accounting for features you don’t use adds friction.

2) Opinionated architecture

Supabase encourages a specific way of structuring your application. That’s great if you want to adopt that model wholesale. Yaldi already had clear boundaries between frontend, API, and storage.

3) Cost predictability

Supabase pricing is reasonable, but once you add traffic, storage, and features you don’t fully control, it becomes harder to reason about marginal cost per request.

Why Neon Was the Right Fit

Neon offers something subtly but importantly different: serverless PostgreSQL. You get real PostgreSQL semantics, but the operational model looks much closer to Lambda than to RDS. Yaldi has been running on Neon for over a year now and I've really loved working with that platform.

1) Pay for usage, not provisioned capacity

Neon decouples compute from storage. Compute can scale down—or even pause—when idle. That aligns perfectly with an API that experiences bursts rather than constant load.

2) Designed for ephemeral connections

Neon is built to handle large numbers of short-lived connections, which makes it a natural match for serverless environments like AWS Lambda. You don’t have to fight the database to make the architecture work.

3) Fast branching and safe experimentation

Neon’s branching model allows you to create isolated database branches almost instantly. This is invaluable for testing migrations, experimenting with schema changes, or validating assumptions without touching production data.

4) Minimal operational surface area

There are no instance sizes to manage, no manual failover planning, and no storage resizing exercises. The database feels more like a service than a machine.

5) PostgreSQL compatibility without compromise

Neon isn’t “Postgres-like.” It is PostgreSQL. Existing tools, libraries, and mental models all carry over cleanly.

Why PostgreSQL on Neon Works Especially Well with Lambda

Lambda and Neon share an important design philosophy: scale to zero when possible, scale out when necessary. This symmetry matters. When both compute and database scale elastically, you avoid mismatches where one layer becomes the bottleneck or the constant cost center. In practice, this means:

  • Lower baseline cost
  • Fewer tuning knobs
  • Less guesswork about future capacity
  • A system that grows naturally with usage

Where Neon Is Not the Right Choice

No database is universally correct. Neon may not be ideal if:

  • You need extremely predictable, sustained high throughput 24/7
  • You rely on database extensions that aren’t supported
  • You want full control over physical replication and networking
  • Your workload is dominated by long-running analytical queries

For those cases, traditional RDS or self-managed PostgreSQL can make more sense. My experience with Neon has been 5 stars and I look forward to building more with them.