Most "Supabase vs Firebase" articles are written by people who spun up a todo app on each platform and called it a day. I've been running 253,000+ records across five production websites on Supabase PostgreSQL for over a year now. I've evaluated Firebase Firestore, PlanetScale, Neon, and Turso for real client projects -- not hypothetical ones. This is what I actually found.

If you're building a web application that needs to handle 100K+ records with complex queries, real-time features, and authentication, your database choice will define your architecture for years. Pick wrong and you're either rewriting your data layer in six months or paying 3x what you should be. I want to save you from both.

Table of Contents

Best Database for 100K+ Record Websites: Supabase vs Firebase vs PlanetScale Tested

Why This Comparison Exists

At Social Animal, we build headless web applications -- primarily with Next.js and Astro -- for clients who need dynamic, data-heavy sites. Think enterprise directories with 50K+ listings, programmatic SEO sites generating thousands of pages, and SaaS dashboards that need real-time updates.

When a client comes to us with a project that involves 100K+ records, the database conversation happens on day one. It's not an afterthought. Your database choice ripples through your auth strategy, your API design, your hosting costs, and your ability to ship features six months from now.

I'm not going to pretend I've run identical production workloads on all five databases. That would be dishonest. What I have done is run serious production on Supabase (253K+ records, five sites, 14 months) and done thorough technical evaluations of the alternatives for specific client projects. I'll be clear about which data comes from production and which comes from evaluation.

The Contenders at a Glance

Before we go deep, here's the quick picture:

  • Supabase -- PostgreSQL with batteries included (auth, storage, realtime, edge functions)
  • Firebase Firestore -- Google's NoSQL document database with excellent mobile SDKs
  • PlanetScale -- Serverless MySQL with database branching (powered by Vitess)
  • Neon -- Serverless PostgreSQL with branching and scale-to-zero
  • Turso -- Distributed SQLite at the edge (powered by libSQL)

Each one is genuinely good at something. The question is whether that something matches what you're building.

Supabase PostgreSQL: Our Production Workhorse

I'll start with Supabase because it's where we have the deepest experience. Across five production sites, our largest table has 137K rows (a national address system for a directory project), and we're at 253K+ total records across all databases.

What We Use Daily

Row Level Security (RLS) is probably the feature that sealed the deal for us. When you're building multi-tenant applications -- which most headless CMS-driven sites eventually become -- you need per-user data isolation. With RLS, the security logic lives in the database itself. Your API layer doesn't need to remember to filter by user_id on every single query. The database enforces it.

Here's what a typical RLS policy looks like in our projects:

-- Users can only see their own organization's listings
CREATE POLICY "org_isolation" ON listings
  FOR SELECT
  USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));

-- Admins can see everything
CREATE POLICY "admin_access" ON listings
  FOR ALL
  USING (EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  ));

This is real SQL. It's not a proprietary DSL. If you ever need to leave Supabase, these policies translate to any PostgreSQL host.

pgvector has been a revelation for semantic search. We implemented it on a content-heavy site where traditional full-text search wasn't cutting it. Users would search for "places to eat near downtown" and expect results that included restaurants, cafes, and food trucks -- even if those exact words weren't in the listing.

-- Create the vector column
ALTER TABLE listings ADD COLUMN embedding vector(1536);

-- Create the index (this matters a LOT at 100K+ records)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- Semantic search query
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;

At 137K records with 1536-dimension vectors, this query returns in ~45ms on Supabase's Pro plan. That's fast enough for real-time search-as-you-type.

PostGIS geo-queries power our location-based features. Finding listings within a radius, sorting by distance, calculating drive times -- all handled at the database level rather than in application code.

-- Find listings within 10km of a point, ordered by distance
SELECT id, name,
  ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
  location,
  ST_MakePoint(-73.9857, 40.7484)::geography,
  10000
)
ORDER BY distance_m
LIMIT 50;

Realtime subscriptions let us build live dashboards without WebSocket infrastructure. A client's admin panel shows new submissions appearing instantly because we subscribe to INSERT events on the relevant table. Zero additional infrastructure.

What's Not Perfect

I won't pretend Supabase is flawless. The dashboard can be sluggish when you're browsing tables with 100K+ rows. The table editor is fine for small datasets but painful for bulk operations -- you'll want to use SQL directly. Their Edge Functions are powered by Deno, which means some Node.js packages don't work. And if you need connection pooling for serverless environments, you have to use their Supavisor connection string (they've deprecated PgBouncer as of early 2025).

Also, their free tier is genuinely generous for development but has a hard limit of 500MB database space. For production with 100K+ records, you're looking at the Pro plan minimum ($25/month).

Best Database for 100K+ Record Websites: Supabase vs Firebase vs PlanetScale Tested - architecture

Firebase Firestore: Where It Wins and Where It Doesn't

We evaluated Firebase seriously for two client projects in 2024. One was a mobile-first application with offline sync requirements. The other was a directory site with complex filtering.

Where Firebase Genuinely Wins

Firebase's real-time sync for mobile applications is still best-in-class. The offline persistence, automatic conflict resolution, and tight integration with iOS/Android SDKs make it the obvious choice if your primary platform is mobile. Google Auth integration is dead simple -- a few lines of code and you've got Sign-in with Google, Apple, phone number, and email/password.

Firebase Crashlytics, Remote Config, and Analytics form a mobile development ecosystem that nothing else matches. If you're building a mobile app first and a web app second, Firebase deserves serious consideration.

Why We Chose Supabase Instead

Firestore is a document database. No joins. Let that sink in for a moment.

When you're building a directory with listings that have categories, tags, locations, reviews, and user profiles, you need relational data. In Firestore, you either denormalize everything (duplicating data across documents and praying you keep it in sync) or you make multiple round-trip queries and join the data in your application code.

Here's what a "find listings by category with average rating" query looks like in each:

-- Supabase: one query, done
SELECT l.*, c.name AS category_name,
  AVG(r.rating) AS avg_rating,
  COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;

// Firestore: three queries + client-side join
const categorySnap = await db.collection('categories')
  .where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;

const listingsSnap = await db.collection('listings')
  .where('categoryId', '==', categoryId).get();

// Now fetch reviews for each listing...
// Then compute averages in application code...
// Then sort... you get the idea.

And here's the real kicker: Firestore charges per document read. That triple-query pattern above? Every document in every query counts. At 100K+ records with moderate traffic, your bill becomes genuinely unpredictable. We've heard horror stories of $400+ surprise bills from developers who didn't realize their queries were scanning more documents than expected.

Firestore also has no equivalent to pgvector or PostGIS. You can do basic geohash queries, but they're approximate and limited compared to true spatial indexing.

PlanetScale: Great Database, Incomplete Platform

PlanetScale runs Vitess under the hood -- the same technology that powers YouTube's database. For pure MySQL performance, it's excellent. Their database branching feature (create a branch, make schema changes, merge back) is genuinely innovative and something I wish Supabase had natively.

What PlanetScale Does Well

Their serverless driver is fast. Connection management is handled for you, which matters enormously in serverless environments where each function invocation might otherwise open a new database connection. Schema branching makes database migrations feel like Git pull requests -- safe, reviewable, reversible.

For teams with strong MySQL expertise building traditional web applications, PlanetScale is solid.

What's Missing

PlanetScale is just a database. That's it. Compare what you need to build a complete application stack:

Feature Supabase PlanetScale + Extras
Database ✅ Included ✅ Included
Auth ✅ Included ❌ Need Clerk ($25+/mo) or Auth0
File Storage ✅ Included ❌ Need S3 or Cloudflare R2
Realtime ✅ Included ❌ Need Pusher or Ably
Vector Search ✅ pgvector ❌ Not available
Geo Queries ✅ PostGIS ❌ Basic MySQL spatial
Edge Functions ✅ Included ❌ Need separate deployment

By the time you've added Clerk for auth, S3 for storage, Pusher for realtime, and a separate vector database for search, you're managing five services instead of one. Your bill is higher, your complexity is higher, and your debugging surface area is enormous.

PlanetScale also sunsetted their free tier (Hobby plan) in April 2024, so the entry point is now $39/month for their Scaler plan. That's more expensive than Supabase Pro and gives you less functionality.

Neon: The Purist's Choice

Neon is the database I'd pick if I just needed PostgreSQL and nothing else. Their serverless architecture is genuinely impressive -- scale-to-zero means you pay nothing when your database isn't being queried. Their branching feature is excellent for preview deployments (spin up a database branch for every PR).

Neon supports pgvector and PostGIS because it's standard PostgreSQL. So you get vector search and geo queries. The raw database capabilities are nearly identical to Supabase.

Why We Still Chose Supabase

Neon is a database. Supabase is a platform. With Neon, you need to add:

  1. Auth -- Clerk, Auth0, or roll your own
  2. Storage -- S3, Cloudflare R2, or similar
  3. Realtime -- Pusher, Ably, or a custom WebSocket server
  4. Edge Functions -- Deploy on Cloudflare Workers or Vercel separately

For some teams, that modular approach is actually preferable. If you already have opinions about auth (and the budget for Clerk), use S3 for everything, and don't need realtime, Neon's focused approach means less vendor lock-in.

But for our headless development projects, having auth, storage, and realtime in one dashboard with one bill and one set of API keys is worth a lot. Developer velocity matters when you're shipping client projects on tight timelines.

Neon's pricing is also competitive: their free tier includes 0.5GB storage and 190 compute hours/month. The Launch plan at $19/month gives you 10GB. For a pure database play, it's the best value in serverless PostgreSQL.

Turso: Edge-First SQLite

Turso is fascinating technology. They've taken SQLite -- the most deployed database in the world -- and made it distributed. Your data lives at the edge, close to your users, which means read latency can be incredibly low (sub-10ms globally).

Where Turso Shines

Read-heavy workloads with global audiences. If you're serving content that doesn't change frequently to users worldwide, Turso's edge replication gives you database reads that feel instant. Their embedded replicas feature lets you bundle a SQLite replica directly in your application.

For static-ish sites with Astro that need a lightweight data layer, Turso is compelling.

Why It Didn't Fit Our Needs

Our 100K+ record workloads involve significant writes -- user submissions, admin updates, review creation, real-time data changes. SQLite's write model (single-writer) becomes a bottleneck at scale. Turso handles this better than raw SQLite through their libSQL fork, but it's still not designed for write-heavy 100K+ record applications.

No vector search. No PostGIS equivalent. Limited ecosystem compared to PostgreSQL or MySQL. For our directory and SaaS projects, these were dealbreakers.

Head-to-Head Feature Comparison

Here's the full comparison table based on our production experience and evaluations as of mid-2025:

Feature Supabase Firebase PlanetScale Neon Turso
Database Type PostgreSQL NoSQL (Firestore) MySQL (Vitess) PostgreSQL SQLite (libSQL)
Built-in Auth ✅ Yes ✅ Yes ❌ No ❌ No ❌ No
Vector Search ✅ pgvector ❌ No ❌ No ✅ pgvector ❌ No
Geo Queries ✅ PostGIS ⚠️ Limited (Geohash) ⚠️ Basic MySQL spatial ✅ PostGIS ❌ No
Realtime ✅ Yes ✅ Yes ❌ No ❌ No ❌ No
File Storage ✅ Yes ✅ Yes ❌ No ❌ No ❌ No
Edge Functions ✅ Deno-based ✅ Cloud Functions ❌ No ❌ No ❌ No
Joins / Relations ✅ Full SQL ❌ No joins ✅ Full SQL ✅ Full SQL ✅ SQL (limited)
Branching ⚠️ Via migrations ❌ No ✅ Native ✅ Native ❌ No
Scale-to-Zero ❌ No ✅ Yes ✅ Yes ✅ Yes ✅ Yes
Pricing Predictability 🟢 High (flat tiers) 🔴 Low (per-read) 🟡 Medium 🟢 High 🟢 High
Open Source ✅ Yes ❌ No ❌ No (Vitess is) ✅ Yes ✅ Yes
Self-Hostable ✅ Yes ❌ No ❌ No ❌ No ✅ Yes

Performance Benchmarks at 100K+ Records

These numbers come from our production Supabase instance (Pro plan, us-east-1 region) with 137K rows in the primary table. For the other databases, I'm using published benchmarks and our evaluation testing with 100K synthetic records.

Query Type Supabase Firebase PlanetScale Neon Turso
Simple SELECT by ID 3ms 8ms 4ms 5ms 1ms
Filtered query (indexed) 12ms 15ms 10ms 14ms 3ms
Complex JOIN (3 tables) 35ms N/A (no joins) 28ms 38ms 25ms
Vector similarity (top 20) 45ms N/A N/A 42ms N/A
Geo radius (10km) 22ms ~50ms (geohash) N/A 24ms N/A
Full-text search 18ms N/A (use Algolia) 15ms 20ms 12ms
Bulk INSERT (1000 rows) 180ms 250ms 150ms 195ms 320ms
Cold start (serverless) N/A (always on) ~100ms ~50ms ~300ms ~20ms

A few things jump out. Turso's read performance is exceptional -- that's the SQLite-at-edge advantage. PlanetScale's MySQL engine handles joins slightly faster than PostgreSQL in our tests. Neon's cold start is noticeable (300ms) because it needs to wake up the compute, though subsequent queries are fast. Firebase's lack of joins means you literally can't run some of these queries.

Supabase's always-on compute (no scale-to-zero on Pro) means zero cold starts, which matters for user-facing applications where that first request can't be slow.

Pricing Breakdown for 100K Record Workloads

Let's model a realistic 100K-record application: a directory site with 100K listings, 50K monthly active users, ~2M database reads/month, ~50K writes/month, 5GB database size, 10GB file storage.

Supabase Pro Firebase (Blaze) PlanetScale Scaler Neon Launch Turso Scaler
Base Cost $25/mo $0 (pay-as-you-go) $39/mo $19/mo $29/mo
Database Included (8GB) ~$18 (reads + writes) Included (10GB) Included (10GB) Included (9GB)
Auth Included (50K MAU) Included +$25/mo (Clerk) +$25/mo (Clerk) +$25/mo (Clerk)
Storage (10GB) Included ~$3/mo +$2/mo (R2) +$2/mo (R2) +$2/mo (R2)
Realtime Included Included +$25/mo (Pusher) +$25/mo (Pusher) +$25/mo (Pusher)
Estimated Total $25/mo ~$21/mo ~$91/mo ~$71/mo ~$81/mo

Firebase looks cheap until you realize two things. First, that $21 estimate assumes predictable read patterns. A viral moment or a bot crawling your site can spike reads dramatically -- and your bill spikes with it. Second, once you need features like vector search, you're adding Pinecone or Weaviate, which starts at $70/month.

Supabase's flat $25/month for everything -- database, auth, storage, realtime, edge functions -- is remarkably good value for this workload size. The Pro plan includes 8GB database, 250GB bandwidth, 100GB storage, and 50K monthly active users for auth.

Which Database Should You Pick?

Here's my honest recommendation based on building with these tools:

Pick Supabase if you're building a web application with relational data, need auth + storage + realtime in one platform, want PostgreSQL's ecosystem (pgvector, PostGIS, full-text search), or you're building with Next.js. This covers probably 80% of the projects we see.

Pick Firebase if you're building a mobile-first application where offline sync matters, your team already knows the Firebase ecosystem, or your data is truly document-shaped (chat messages, activity feeds, simple user profiles).

Pick PlanetScale if you have a strong MySQL team, need database branching for complex schema management, and you're already using separate services for auth and storage. It's a great database -- just not a complete platform.

Pick Neon if you want PostgreSQL without the platform overhead, prefer assembling your own stack from best-of-breed services, or need scale-to-zero for cost optimization on low-traffic projects.

Pick Turso if you're building a read-heavy, globally distributed application where edge latency matters more than write throughput, or you're working with Astro on content-focused sites.

For our work at Social Animal building headless web applications, Supabase has been the right call. The all-in-one platform means faster development, simpler architecture, and predictable costs. We've scaled it to 253K+ records without breaking a sweat. If you're planning a project at this scale and want to talk architecture, reach out to us -- we've done this a few times now.

FAQ

Is Supabase good for large-scale applications? Yes, and we have production evidence to back that up. We're running 253K+ records across five production sites on Supabase Pro. Query performance stays consistent -- our most complex joins with vector similarity search return in under 50ms at 137K rows. Supabase runs on standard PostgreSQL, which powers applications orders of magnitude larger than anything most of us will build. The platform layer (auth, storage, realtime) is the part that's newer, but it's been stable for us since early 2024.

How does Supabase pricing compare to Firebase at scale? Supabase is dramatically more predictable. Their Pro plan is a flat $25/month that includes auth for 50K MAUs, 8GB database storage, 250GB bandwidth, and 100GB file storage. Firebase charges per document read, write, and delete -- which makes costs highly variable. A 100K-record application with 2M monthly reads could cost anywhere from $15 to $200+ on Firebase depending on query patterns. We've seen Firebase bills triple overnight when a page gets shared on social media.

Can PlanetScale handle 100K+ records? Absolutely. PlanetScale runs Vitess, which powers YouTube-scale workloads. For raw database performance with 100K records, PlanetScale is excellent. The limitation isn't scale -- it's completeness. You'll need to add separate services for auth, file storage, realtime updates, and vector search. That adds both cost ($90+/month total) and architectural complexity compared to Supabase's all-in-one approach.

What is pgvector and why does it matter? pgvector is a PostgreSQL extension that stores and queries vector embeddings directly in your database. This enables semantic search -- users can search by meaning rather than exact keywords. For a directory with 100K+ listings, this means a search for "kid-friendly brunch spots" can return results tagged as "family restaurant" or "weekend breakfast" even though those words don't match. Without pgvector, you'd need a separate vector database like Pinecone ($70+/month) and deal with keeping two databases in sync.

Is Firebase Firestore good for directory websites? Honestly, no. Directory websites are inherently relational. Listings belong to categories, have tags, receive reviews from users, and need complex filtering ("show me restaurants within 5 miles with 4+ stars that are open now"). Firestore can't do joins, has limited query operators, and charges per document read -- which means complex filtered queries get expensive fast. We evaluated Firestore for a directory project and estimated 4x the development time compared to Supabase due to data denormalization and client-side query workarounds.

Should I use Neon or Supabase for my Next.js app? If you need just a database, Neon offers better value (free tier is generous, and the $19/month Launch plan is solid). If you need auth, storage, realtime, or edge functions -- which most production Next.js apps do -- Supabase saves you from integrating and paying for multiple separate services. We use Supabase for our Next.js development projects because the integrated auth and storage cut weeks off typical project timelines.

What's the best database for programmatic SEO sites? Supabase PostgreSQL. Programmatic SEO sites generate thousands of pages from structured data, which means you need fast queries, good indexing, and the ability to handle complex data relationships. We've built programmatic SEO sites on Supabase that generate 10K+ pages from a single database -- PostGIS for location pages, pgvector for related content, and full-text search for dynamic filtering. The flat pricing means traffic spikes from Google indexing don't blow up your bill.

Is Turso (libSQL) ready for production web apps? For read-heavy applications, yes. Turso's edge-replicated SQLite gives you sub-5ms reads globally, which is incredible for content-focused sites. But for write-heavy applications with 100K+ records -- like directories where users submit data, admin panels process updates, and reviews come in constantly -- SQLite's single-writer model becomes limiting. We'd recommend Turso for content sites built with Astro and Supabase or Neon for dynamic applications with significant write workloads.