Serverless PostgreSQL for Laravel: Neon vs Aurora vs Supabase

Laravel Went Serverless. Your Database Should Too.

Laravel Cloud runs on Neon. That's not speculation. Taylor Otwell's managed hosting platform chose Neon's serverless PostgreSQL as its database layer. When the creator of Laravel picks a database provider for his own infrastructure product, the rest of us should pay attention.

But Neon isn't the only serverless PostgreSQL option. Aurora Serverless v2 has AWS behind it. Supabase has a massive developer community. All three offer PostgreSQL that scales automatically and can hibernate when idle.

We run multiple Laravel projects at Cafali across different hosting environments. This post compares all three from a Laravel developer's perspective: connection setup, migration workflow, scale-to-zero behavior, cold starts, branching, pricing, and the things that actually matter when your .env file hits production.

No auth services. No edge functions. No storage buckets. Just the database.

What "Serverless PostgreSQL" Actually Means for Laravel

Traditional PostgreSQL runs on a server you provision. You pick the instance size, you pay whether it's busy or idle, and if traffic spikes beyond your capacity, you scramble to upgrade.

Serverless PostgreSQL changes three things:

Autoscaling. The database adjusts compute automatically based on load. A quiet Sunday morning uses minimal resources. A product launch on Monday morning scales up without you touching anything.

Scale to zero. When nobody is querying the database, compute shuts down entirely. You stop paying. When the next request arrives, the database wakes up.

Pay per use. You're billed for the compute time you actually consume, not for a server sitting idle overnight.

For Laravel specifically, this matters because most Laravel applications have highly variable traffic patterns. An admin panel that gets 50 queries during business hours and zero at night. A SaaS product that spikes during onboarding campaigns. A client project in staging that sits untouched for days between review cycles.

With a traditional database, you pay full price for all of it. With serverless, you pay for the queries.

Neon: What Laravel Cloud Chose

Neon is serverless PostgreSQL built from the ground up. It separates storage from compute, which is what enables its most distinctive features.

Laravel setup is standard PostgreSQL configuration:

DB_CONNECTION=pgsql
DB_HOST=ep-cool-darkness-123456.us-east-2.aws.neon.tech
DB_PORT=5432
DB_DATABASE=neondb
DB_USERNAME=neondb_owner
DB_PASSWORD=your-password

No special drivers. No SDK. Laravel's built-in PostgreSQL support works out of the box. Neon even publishes an official Laravel guide and a setup prompt for AI coding agents.

Scale to zero is where Neon stands apart. When your database has no active connections, compute suspends within 1-5 minutes (configurable). When the next query arrives, the database resumes in under a second. That cold start time matters. Under a second means your first user of the day might not even notice the database was asleep.

Database branching is Neon's killer feature for Laravel development. You can create an instant copy-on-write branch of your production database for:

• Running migrations against real data before deploying
• Each pull request getting its own database branch for CI/CD
• Testing destructive operations without touching production
• Giving each developer a full copy of the database without duplicating storage

Branches share the underlying storage and only consume space for the data that changes. Creating a branch of a 50GB database takes seconds, not hours, and costs nothing until you write to it.

For Laravel teams running php artisan migrate against production with crossed fingers, branching is the safety net that should have existed years ago.

Connection pooling via PgBouncer is included at no extra cost. Laravel's persistent database connections work through Neon's pooler without configuration changes.

Pricing: Free tier includes 100 compute-hours and 0.5GB storage per project. Paid plans start at $0.106 per compute-unit-hour with $0.35 per GB-month for storage. No monthly minimum.

Aurora Serverless v2: The Enterprise Option

Amazon's Aurora Serverless v2 is PostgreSQL running on AWS's custom storage engine. It's designed for companies already deep in the AWS ecosystem.

Laravel setup uses standard PostgreSQL credentials from RDS:

DB_CONNECTION=pgsql
DB_HOST=your-cluster.cluster-abc123.us-east-1.rds.amazonaws.com
DB_PORT=5432
DB_DATABASE=your_database
DB_USERNAME=postgres
DB_PASSWORD=your-password

Autoscaling works in 0.5 ACU (Aurora Capacity Unit) increments. One ACU is roughly 2GB of memory. The scaling is fine-grained and automatic, though it doesn't scale as aggressively to zero as Neon does.

Scale to zero was added more recently with "automatic pause and resume." When there are no active connections, Aurora can suspend the cluster. The catch: cold starts take 15-30 seconds. For a background job worker, that's fine. For a web request from a real user, 15-30 seconds of loading screen is unacceptable.

No branching. You can create read replicas and snapshots, but there's no instant copy-on-write branching like Neon offers. Testing migrations against production data requires restoring a snapshot to a separate cluster, which takes minutes to hours depending on database size.

Connection pooling requires RDS Proxy, which is a separate service with its own pricing. It works well but adds cost and configuration complexity.

Pricing: No free tier. You pay from the first minute. ACU-hours cost roughly $0.12 each. Storage is included in ACU pricing. RDS Proxy adds approximately $0.015 per hour per vCPU.

Where Aurora wins: If your Laravel application runs on AWS (EC2, ECS, Lambda), Aurora offers the lowest network latency and tightest integration. IAM authentication, VPC peering, and the entire AWS security model work natively. For enterprise applications with compliance requirements, Aurora's certifications and audit trail are hard to match.

Supabase: PostgreSQL Plus Everything (But We Only Want the Database)

Supabase markets itself as a Firebase alternative with auth, storage, edge functions, and realtime subscriptions. But strip all that away and what's left is a solid managed PostgreSQL instance.

Laravel setup is identical to any PostgreSQL connection:

DB_CONNECTION=pgsql
DB_HOST=db.your-project-ref.supabase.co
DB_PORT=5432
DB_DATABASE=postgres
DB_USERNAME=postgres
DB_PASSWORD=your-password

The database itself is full PostgreSQL with extensions like pgvector, PostGIS, and pg_cron available out of the box. You get direct postgres level access, which means no restrictions on what you can do with Eloquent, raw queries, or custom extensions.

Scale to zero is available on the free tier (pauses after 1 week of inactivity) but paid projects stay always-on by default. Supabase's architecture doesn't separate compute from storage the way Neon does, so the hibernation model is less refined.

No autoscaling in the traditional sense. You choose a compute size (Micro, Small, Medium, etc.) and it stays at that size until you manually change it. There's a "read replicas" feature for distributing read traffic, but compute doesn't dynamically adjust based on load.

Connection pooling via Supavisor (PgBouncer-based) is included.

No branching. Like Aurora, there's no instant database branching. You get point-in-time recovery and manual backups, but no copy-on-write branches for development workflows.

Pricing: Free tier includes 500MB database space and 50,000 monthly active users (for auth, which we're ignoring). Pro plan starts at $25/month for 8GB database space and dedicated compute. You're paying for a fixed compute tier, not per-query.

Where Supabase wins: If you eventually want realtime subscriptions, row-level security policies, or a built-in REST API alongside your Laravel application, Supabase offers all of that on top of the database. The dashboard is also excellent for visual database management. But for pure database-only use, you're paying for features you won't use.

The Comparison That Matters for Laravel

Our Recommendation by Use Case

For most Laravel projects: Neon.

The combination of sub-second cold starts, database branching, and the fact that Laravel Cloud itself runs on Neon makes it the default choice. The free tier is generous enough for development and staging. The paid tier scales smoothly into production. Branching alone changes how you think about migrations and testing.

For enterprise Laravel on AWS: Aurora Serverless v2.

If your company runs everything on AWS, Aurora's integration with IAM, VPC, and the broader AWS security model is hard to replace. The cold start issue is real, but if your production database stays active (never scaling to zero), it doesn't matter. Use Neon for dev/staging and Aurora for production if you need the AWS compliance story.

For Laravel projects that will grow beyond the database: Supabase.

If you know your application will eventually need realtime features, row-level security, or a REST API alongside Laravel, starting with Supabase means you won't need to migrate later. But if you only need a database, you're paying for a platform you won't fully use.

For development and staging environments: Neon, always.

Even if you run Aurora or Supabase in production, Neon's branching and free tier make it the best choice for development. Create a branch per PR, run migrations safely, and pay nothing until your project goes live.

The Laravel Connection

Laravel 13 supports PostgreSQL as a first-class database. Eloquent, migrations, queues, cache, sessions, all of it works with PostgreSQL without modification. The framework doesn't care whether your PostgreSQL is on a $5 VPS or a serverless cluster that scales to zero.

What changed is the infrastructure around it. Laravel Cloud choosing Neon signals where the ecosystem is heading: serverless databases that match Laravel's own deployment model. You deploy your application without thinking about servers. Your database should work the same way.

At Cafali, we've been moving client projects to Neon for development and staging environments. The branching workflow alone has saved us from multiple migration incidents. For production, we evaluate based on the client's existing infrastructure and compliance needs.

If you're starting a new Laravel project in 2026, the question isn't whether to use serverless PostgreSQL. It's which one fits your stack.

At Cafali, we build Laravel applications with modern infrastructure. If you need help evaluating your database stack or migrating to serverless PostgreSQL, let's talk.