Traditional RDS instances suffer from insufficient connection pools, slow cold starts, and wasteful hourly billing. Serverless databases promise pay-as-you-go pricing, infinite scaling, and edge computing optimization, but there are too many products with overlapping features yet distinct characteristics. Supabase calls itself “open-source Firebase,” Neon touts “separated storage and compute,” PlanetScale claims “MySQL without migrations,” and Turso promises “distributed SQLite.”
This article tests five mainstream solutions, examining cold start latency, edge deployment compatibility, pricing transparency, and ecosystem maturity to determine which best suits Next.js projects.
1. Supabase: BaaS Suite, More Than Just a Database
Supabase isn’t just a database—it’s a complete Backend-as-a-Service platform. You get Postgres + authentication + storage + real-time subscriptions + Edge Functions, solving all backend needs for Next.js projects in one place.
**Core Advantages:**
– **Full-featured Postgres**: RLS (Row Level Security), PostGIS (geospatial data), full-text search, JSON support—enterprise-grade features included
– **Authentication out of the box**: Email, OAuth (Google/GitHub), Magic Link—no need to write login logic yourself
– **Real-time subscriptions**: Database changes automatically pushed to frontend, perfect for collaboration tools and real-time dashboards
– **Edge Functions**: Deno Runtime deployed on Cloudflare Workers, cold start < 50ms
**Best Use Cases:** Full-stack Next.js projects, especially those requiring real-time functionality. For example, a team collaboration SaaS where user A’s modifications need to immediately sync to user B’s interface—Supabase Realtime solves this directly without building WebSocket infrastructure yourself.
Another scenario: indie hacker MVPs. Registration + login + database + file upload—Supabase’s free tier covers it all. A solo developer can build a complete backend in a week and focus on frontend logic.
**Pricing:**
– **Free**: 500MB database + 1GB file storage + 50,000 monthly active users
– **Pro**: $25/month, 8GB database + 100GB storage
– **Team/Enterprise**: Custom pricing
Honestly, Supabase’s free tier is the most generous among competitors. 50,000 MAU is sufficient for most side projects for a long time. However, the jump to $25/month after exceeding limits is steep for database-only projects—because you’re paying for authentication, storage, and Functions infrastructure even if you don’t use them.
**Performance Considerations:** Supabase’s Postgres instances aren’t “true serverless”—they’re managed instances with on-demand hibernation. Free tier projects pause after 7 days of inactivity, requiring wake-up on first access (approximately 5-10 seconds). For production workloads, this wake-up delay is unacceptable, so you’ll want the Pro tier with always-on instances.
Connection pooling is handled through PgBouncer, supporting up to 60 direct connections on the free tier and 200 on Pro. For Next.js applications deployed on Vercel or similar serverless platforms, each function invocation can potentially create a new connection, so the pooled connection mode is essential.
**Migration and Lock-in:** Data export is straightforward (Postgres dump), but migrating authentication users and storage files requires manual handling. Supabase stores user authentication data in the `auth.users` table, which you can export, but OAuth tokens and refresh tokens are encrypted with Supabase’s keys. If you migrate away, users will need to re-authenticate. Storage files can be downloaded via the Storage API, but you’ll need to rewrite file paths in your database.
**Real-World Example:** A SaaS dashboard builder started on Supabase’s free tier with 200 users. They used RLS policies to isolate each customer’s data, Supabase Auth for login, and Storage for uploaded logos. After 6 months, they had 5,000 users and were paying $25/month on Pro. The authentication system saved them weeks of development time, and the real-time subscriptions enabled live dashboard updates without building WebSocket infrastructure. The main pain point: debugging RLS policies can be tricky, requiring careful testing to avoid accidental data leaks.
2. Neon: Serverless Postgres with Separated Architecture
Neon focuses on one thing: making Postgres truly serverless. Its architecture separates storage and compute—data lives in S3 while the compute layer starts and scales on demand. This brings two core advantages: billing based on actual usage and extremely fast branch creation (similar to Git branches).
**Core Advantages:**
– **True serverless architecture**: Compute layer automatically hibernates, zero cost during zero activity. Cold start latency approximately 500ms-1s.
– **Database branching**: Each PR can create an independent database branch, isolating preview environments from production data
– **No connection pool limits**: Traditional Postgres maxes out at a few hundred connections; Neon handles tens of thousands of concurrent connections through its pooling layer
– **Time Travel**: Free tier retains 7 days of history, paid tiers 30 days—roll back to any point in time
**Best Use Cases:** Next.js projects deployed on Vercel needing separate databases for each preview deployment. Neon’s branching feature perfectly aligns with Vercel’s PR preview workflow—automatically create database branches on each push, automatically delete on merge, delivering a seamless development experience.
Another scenario: projects with fluctuating traffic. For example, a news site with typical 100 QPS that suddenly spikes to 10,000 QPS during breaking news. Neon’s compute layer automatically scales up during peaks and scales back down afterward, charging only for actual usage.
**Pricing:**
– **Free**: 0.5GB storage + 191 compute hours/month (approximately 6 hours daily)
– **Launch**: $19/month, 10GB storage + 300 compute hours
– **Scale**: Starting at $69/month, tiered usage-based pricing
Neon’s billing model is more transparent than Supabase. If your project only has traffic during business hours with automatic hibernation nights and weekends, monthly costs can stay quite low. However, for 24/7 high-traffic projects, compute time costs accumulate rapidly.
**Performance in Practice:** Cold start latency (500ms-1s) is slower than Supabase, unsuitable for scenarios requiring extremely fast initial response times. However, once warmed up, query performance is identical to standard Postgres. Neon keeps the compute layer active for 5 minutes after the last query, so in practice, cold starts only affect the first request after idle periods.
Neon’s connection pooling handles up to 10,000 concurrent connections through their proxy layer, making it ideal for serverless deployments where connection count can spike unpredictably. They use a custom connection pooler that’s more efficient than PgBouncer for serverless workloads.
**Branching Workflow:** The branching feature is Neon’s killer app. Creating a branch takes under 1 second because it’s copy-on-write—only delta changes are stored. You can create a branch from production data, run migrations or tests, then delete it without affecting production. This is transformative for CI/CD pipelines.
**Real-World Example:** An e-commerce platform on Vercel uses Neon for its database. Every PR automatically gets a preview deployment with its own database branch seeded from production data. Developers can test checkout flows with real product data without risking production. When the PR merges, the branch is automatically deleted. Their monthly Neon bill averages $35 because the staging and preview branches only exist during active development, and production hibernates during off-peak hours (midnight to 6am PST).
**Cost Gotcha:** The 191 free compute hours sound generous, but they’re consumed whenever the database is active, not just during queries. If you have a cron job checking the database every minute, your database never hibernates. They hit the 191-hour limit in 8 days and had to upgrade to Launch tier. Solution: batch cron jobs and use Neon’s query API to check if data exists before waking the database.
3. PlanetScale: MySQL Without Migrations
PlanetScale is built on Vitess (the MySQL sharding solution YouTube uses to handle 1 billion users), providing “non-blocking schema changes” and “branch development” capabilities. Its philosophy: database schema changes should be as safe and predictable as code deployments.
**Core Advantages:**
– **Non-blocking schema changes**: Alter table structures without locking, zero downtime in production
– **Branches and Deploy Requests**: Change schemas on branches, test thoroughly, then merge to main—similar to Git workflow
– **Automatic sharding**: When data grows beyond single-server bottlenecks, PlanetScale automatically shards horizontally with no application-layer awareness
– **Built-in connection pooling**: No need to configure PgBouncer or connection pooling yourself
**Best Use Cases:** Medium to large team-based Next.js projects with frequent schema changes. Traditional MySQL migrations require downtime and carry high rollback risk—PlanetScale’s Deploy Requests turn schema changes into reviewable, rollback-capable processes.
Another scenario: the path from small project to large project. Starting with a few tens of thousands of rows in a single table, then growing to millions of users—PlanetScale automatically shards without code rewrites.
**Pricing:**
– **Hobby**: 5GB storage + 10 billion row reads/month + 10 million row writes/month, free (free tier restored in 2024)
– **Scaler**: Starting at $39/month, billed by read/write rows
– **Enterprise**: Custom contracts
PlanetScale was heavily criticized after eliminating its free tier in 2023, then restored it in 2024. However, the free tier has tighter restrictions than Neon and Supabase (only 1 production branch, no Deploy Requests). Teams needing branching functionality require at least the Scaler plan.
**MySQL Limitations:** **MySQL is not Postgres**. No advanced JSON field queries, no RLS, no PostGIS. If your project depends on Postgres features, PlanetScale isn’t suitable. JSON support exists but is more limited—no JSONB, no GIN indexes on JSON fields.
The foreign key controversy deserves explanation: In April 2026, PlanetScale dropped support for foreign key constraints. Their reasoning: when data is sharded across multiple servers, enforcing foreign keys requires cross-shard transactions that kill performance. Instead, they recommend enforcing referential integrity in application code. This is acceptable for new projects designed with this constraint in mind, but a dealbreaker for migrating existing Django or Rails apps that rely heavily on database-level constraints.
**Deploy Request Workflow:** PlanetScale’s Deploy Requests are GitHub PRs for your database. You create a branch, apply schema changes, test thoroughly, then open a Deploy Request. Team members review the changes, PlanetScale generates a detailed diff showing exactly what will change, and you can safely merge to production without downtime. The merge process uses Vitess’s online schema change algorithm—creating shadow tables, copying data incrementally, then swapping atomically.
**Real-World Example:** A fintech startup with 12 engineers uses PlanetScale for their transaction processing system. They ship database schema changes weekly. Before PlanetScale, MySQL migrations required maintenance windows and caused production incidents twice. With Deploy Requests, schema changes go through code review like any other code. Last month they added a new index on a 50-million-row table—it took 4 hours but didn’t lock the table or cause downtime.
Their one complaint: the hobby tier doesn’t support Deploy Requests, forcing them to Scaler tier at $39/month even though their data size is only 2GB. For small teams, this makes PlanetScale more expensive than alternatives.
**Sharding Transparency:** PlanetScale’s automatic sharding is impressive but not magic. You still need to design your schema with sharding in mind—choose good shard keys (usually user_id or tenant_id). If you query across shards frequently, performance suffers. Their dashboard shows shard distribution, and you can manually rebalance if needed.
4. Turso: SQLite for Edge Computing
Turso is the most unconventional choice—it’s neither Postgres nor MySQL, but libSQL (a SQLite fork). The core selling point: “SQLite but distributed,” with database instances deployed on global edge nodes for query latency < 10ms.
**Core Advantages:**
– **Extremely low latency**: Database replicas deployed on edge nodes closest to users, queries don’t need to cross continents
– **Embedded compatibility**: Use SQLite files directly during local development, data automatically syncs when deploying to Turso
– **Billing by database instance count**: Not by storage or traffic, but by how many databases you create
– **Multi-tenant friendly**: Each tenant gets an independent database instance, naturally isolated
**Best Use Cases:** Global Next.js SaaS with users distributed across continents. For example, a collaboration tool where US users access US node database replicas and European users access European nodes—query latency drops from 200ms to 5ms, delivering a qualitatively better user experience.
Another scenario: multi-tenant B2B SaaS. Each enterprise customer gets an independent database instance (database-per-tenant architecture), thorough data isolation, low compliance risk.
**Pricing:**
– **Starter**: 8GB storage + 1 location + 500 databases, free
– **Scaler**: $29/month, additional locations $10/location/month
– **Enterprise**: Custom pricing
Turso’s pricing model suits multi-tenant scenarios. If your SaaS has 500 enterprise customers, each with their own database, Turso’s free tier suffices. The same scenario on Supabase or Neon would require billing separately for each tenant’s data volume.
**SQLite Ecosystem Tradeoffs:** SQLite’s ecosystem is smaller than Postgres/MySQL. No PostGIS, no full-text search (requires separate integration through libSQL extensions), ORM support is improving but still behind. Prisma supports libSQL, but some advanced features like native database triggers aren’t available.
Writes replicate to all edge nodes through a consensus protocol, making cross-region write latency higher than single-region. A write from the US might take 200ms to replicate to Asia. Turso uses a primary region for writes and read replicas everywhere else. You can configure write latency tolerance vs. consistency tradeoffs.
**Multi-Tenant Architecture:** Turso shines in database-per-tenant architectures. Traditional shared-schema multi-tenancy (all tenants in one database with `tenant_id` columns) risks data leaks and makes per-customer backups difficult. With Turso, each tenant gets a physically isolated database, deployed on edge nodes near their users. Migrations run across all tenant databases automatically.
**Real-World Example:** A project management SaaS uses Turso with database-per-tenant architecture. They have 300 customers, each with their own database instance. Total cost: $0 (fits in Starter tier’s 500 database limit). Query latency for their Australian customers dropped from 300ms (Neon in us-east-1) to 15ms (Turso Sydney edge). They use Prisma with libSQL adapter, and migrations run via a custom script that iterates through tenant databases.
The main challenge: some customers have large datasets (100MB+), and edge storage isn’t free beyond the included quota. They’re considering a hybrid approach—large customers on dedicated Neon instances, small customers on Turso edge.
**Local Development:** Turso’s local development story is excellent. You can use `turso dev` to run a local libSQL server that’s API-compatible with production, or just use SQLite files directly. This makes offline development seamless—no need for Docker containers running Postgres.
5. Firebase (Firestore): NoSQL with Mature Ecosystem
Firebase is Google’s BaaS platform, with Firestore as its NoSQL database. Although not a SQL database, it’s worth considering due to mature Next.js integration and rich ecosystem.
**Core Advantages:**
– **Real-time sync**: Data changes automatically pushed to all clients, perfect for chat and collaboration tools
– **Offline support**: Local caching + automatic sync, good experience in weak network environments
– **All-in-one**: Authentication + database + storage + Analytics—even more comprehensive than Supabase
– **Generous free tier**: 1GB storage + 50K reads/day + 20K writes/day
**Best Use Cases:** Mobile-first projects requiring offline support. For example, a Next.js + React Native cross-platform app where users operate in the subway and data automatically syncs when they emerge—Firestore’s offline mode natively supports this.
Another scenario: MVP prototype validation. Firestore’s flexible schema enables rapid iteration on data structures without writing migrations. After product validation and data model stabilization, consider whether to migrate to SQL.
**Pricing:**
– **Spark (free)**: 1GB storage + 50K reads/day + 20K writes/day
– **Blaze (pay-as-you-go)**: $0.18/GB storage/month + $0.06/100K reads + $0.18/100K writes
Be careful with Firestore’s read/write billing. Poorly optimized queries that scan many documents can cause costs to spike. Enable budget alerts.
**NoSQL Constraints:** NoSQL means no JOINs, no transactions (across documents), no complex queries. Firestore transactions work within a single document or a small batch, but you can’t do multi-table joins like SQL. This forces denormalization—copying data across documents to avoid needing joins. For example, if you have users and posts, you’d store the author’s name in every post document rather than joining on user_id.
Complex queries require composite indexes that you must create manually. Firestore won’t let you query without an index, and creating indexes takes time (sometimes hours for large datasets). This is good for performance but frustrating during development when you want to quickly test a query.
**Vendor Lock-In Reality:** Heavy vendor lock-in. Firestore’s data format and query API are Google proprietary—migrating to other databases requires rewriting substantial code. The security rules syntax is unique to Firebase, so all your access control logic must be rewritten. Real-time listeners use Firebase’s WebSocket protocol, not standard WebSockets.
**When Firestore Shines:** Firestore excels for real-time collaborative apps. The offline persistence layer is production-ready out of the box—users can work offline, and changes sync automatically when connectivity returns. This is notoriously hard to build correctly with SQL databases.
**Real-World Example:** A team collaboration tool uses Firestore for real-time document editing (think Google Docs clone). When user A types, user B sees updates within 100ms. Firestore’s real-time listeners handle the synchronization automatically. They have 2,000 active documents, each with 10-50 collaborators. Monthly Firestore bill: $80.
They hit one major limitation: reporting and analytics. Aggregating data across documents (e.g., “how many tasks completed this month?”) is painful in NoSQL. They ended up exporting Firestore data to BigQuery daily for analytics, adding complexity and cost.
**Cost Management:** Firestore’s per-operation pricing can surprise you. A poorly structured query that scans 10,000 documents counts as 10,000 reads. They implemented query result caching in their Next.js API routes and reduced read operations by 70%. Enable Firebase budget alerts—you don’t want a $1,000 surprise bill.
Comparison Table
| Database | Type | Cold Start Latency | Edge Deployment | Free Tier | Best Use Cases |
|———-|——|——————-|—————–|———–|—————-|
| **Supabase** | Postgres (BaaS) | 5-10s (wake-up) | ❌ | 500MB + 50K MAU | Full-stack Next.js, needs auth + real-time |
| **Neon** | Postgres (Serverless) | 500ms-1s | ✅ (read replicas) | 0.5GB + 191h/month | Vercel deployment, fluctuating traffic |
| **PlanetScale** | MySQL (Serverless) | < 1s | ❌ | 5GB + limited branches | Frequent schema changes, team collaboration |
| **Turso** | SQLite (Edge) | < 100ms | ✅ (global) | 8GB + 500 databases | Global users, multi-tenant isolation |
| **Firestore** | NoSQL (BaaS) | < 100ms | ✅ | 1GB + 50K reads/day | Mobile + offline support |
Selection Recommendations
**Full-stack Next.js, solo developer:** Supabase. Authentication, database, storage all included—no need to integrate multiple services. Free tier lasts a long time.
**Deployed on Vercel, need preview environments:** Neon. Database branching feature perfectly aligns with Vercel’s PR preview workflow, best development experience.
**Team collaboration, frequent schema changes:** PlanetScale. Deploy Requests turn database changes into reviewable processes, avoiding production incidents.
**Global product, users across continents:** Turso. Edge node deployment reduces query latency to under 10ms, noticeably improving experience.
**MVP rapid validation, uncertain data structure:** Firestore. NoSQL flexibility enables rapid iteration—consider migration once model stabilizes.
**Existing Postgres skills, don’t want to learn new things:** Neon or Supabase. Both are standard Postgres, directly reusing existing knowledge.
Common Misconceptions
**Misconception 1: “Serverless databases are always cheaper than traditional RDS”**
Not necessarily. For projects with 24/7 high traffic, Neon’s compute time costs may exceed RDS instance costs. Serverless advantages shine in fluctuating or low-traffic scenarios.
**Misconception 2: “Edge databases always have low latency”**
Only true for read operations. Write operations require cross-region replication, potentially increasing latency. Turso suits read-heavy scenarios, not high-frequency writes.
**Misconception 3: “Free tier sufficiency means forever free”**
Free tiers typically have hidden limitations: Supabase pauses after 7 days of inactivity, PlanetScale’s free tier can’t use branches, Neon only provides 191 monthly compute hours. Calculate actual costs carefully.
Conclusion
There’s no silver bullet for Next.js database selection. Supabase suits rapid full-stack development, Neon fits the Vercel ecosystem, PlanetScale works for team collaboration, Turso excels for global reach, and Firestore enables prototype validation.
The core of selection: What stage is your project at? Solo MVP, 5-person team, or 50-person company? Where are your users? What’s your traffic pattern? Answer these questions and the choice becomes clear.
One final recommendation: don’t over-optimize. For early-stage projects, choose Supabase or Neon, then optimize once user growth hits bottlenecks. Database migration costs aren’t as high as you think, but time wasted on premature optimization is real.
Stay updated with our latest AI insights
