Our Database Bill Went From $2,300 to $980

Supabase: The Predictable Optimizer's Dream

Supabase doesn't fuck around with complicated usage metrics like the others. You pay for compute, storage, and bandwidth. That's it. No hidden bullshit. Here's what I've figured out after a year of dealing with their billing:

Spend Caps Actually Work (Unlike Budget Alerts That Just Mock You)

Turn on spend caps immediately. Firebase's budget alerts are fucking useless - they email you after you've already blown your budget. Supabase actually stops service when you hit the cap.

I set ours to about 150% of expected usage. Good thing too - our staging env got stuck in some kind of loop pulling data and would've racked up maybe $380 in charges. Instead it hit the cap at $50 and just stopped working. Annoying, but not budget-destroying.

Micro Instances Can Handle More Than You Think

Don't fall for their upselling bullshit. I'm running about 12k DAU on just the Micro compute addon - $10/month. Yeah it gets a bit slow when we have traffic spikes but most of the time it's totally fine. Their dashboard actually shows you real CPU usage so you can tell if you need more power instead of just guessing.

The usage dashboard is way better than Firebase's confusing cost breakdown that makes zero fucking sense.

Database Storage Optimization

Supabase storage is cheap as hell compared to PlanetScale, but it still adds up:

• Archive old data using pg_partman for time-based partitioning
• Use PostgreSQL compression for large text fields
• Regular VACUUM ANALYZE to reclaim space from deleted records
• Optimize indexes - each unnecessary index costs storage and slows writes

Real-Time Connection Management

Real-time subscriptions can consume unexpected resources. Limit concurrent connections per user, implement connection pooling client-side, and use presence feature sparingly - it's resource-intensive.

Firebase: Taming the Usage Beast

Firebase bills you for every single fucking operation and somehow their cost dashboard makes it impossible to figure out what's actually expensive. Plus they have this shitty thing where real-time listeners trigger cascading reads that aren't obvious until you get the bill.

Firebase's Query Optimization Is A Pain In The Ass

Firestore charges about $0.06 per 100,000 reads which sounds reasonable until you discover that clicking a "like" button somehow triggers 35 document reads. Had to trace through our code with the Firebase console open to figure out where all these reads were coming from:

• Use composite queries instead of multiple single-field queries
• Implement pagination with limit() - never fetch more than you display
• Cache query results client-side using Firebase caching
• Use real-time listeners judiciously - each update triggers new reads

Cloud Functions Will Eat Your Budget

Cloud Functions pricing is sneaky - it's not just invocations, it's compute time and memory too. Cold starts are expensive and happen more than you think.

We moved our image processing functions to Cloud Run because Functions was bleeding us $150/month for what should've been simple fucking tasks. Cloud Run handles the same workload for around $65.

Pro tip: functions default to 256MB memory but most only need 128MB. Firebase doesn't tell you this, so you're paying double for memory you're not using. Check your function metrics - if you're consistently under 128MB usage, downgrade the memory allocation.

Storage and CDN Optimization

Cloud Storage pricing varies significantly by region and access pattern:

• Use regional storage for frequently accessed files
• Implement lifecycle policies to move old files to cheaper storage classes
• Enable CDN caching to reduce egress charges
• Compress images before upload - Firebase doesn't do this automatically

PlanetScale: High-Performance Cost Engineering

PlanetScale costs way more than the others but you know exactly what you're paying for. Storage is $1.50/GB which is pretty steep - like 10x what you'd pay for Supabase storage.

PS-10 Is Actually A Decent Deal (If You Use It Right)

PlanetScale forces you into 3 instances minimum for production (1 primary + 2 replicas). The PS-10 at $39/month includes all three, which is reasonable for small workloads.

The thing they don't emphasize is that database branches consume storage too. I heard about one team that had like 12 dev branches sitting around for months and got hit with an $800 storage bill. Ouch.

The PlanetScale CLI doesn't warn you about costs when creating branches. You just run pscale branch create my-feature and boom, you're paying for storage. Delete branches right after merging or you'll get hit with a surprise bill.

Storage Will Bankrupt You

Storage will kill your budget fast. We're paying $150/month for about 100GB of data, which feels ridiculous:

• Implement data archiving strategies using GitHub Actions
• Use query insights to identify unused tables and columns
• Implement horizontal sharding before vertical scaling
• Regular schema optimization to remove unused indexes

Migration and Deployment Optimization

Zero-downtime migrations are PlanetScale's killer feature, but they consume resources during deployment:

• Schedule large migrations during low-traffic periods
• Use deploy requests to batch multiple schema changes
• Monitor replication lag during migrations
• Clean up development branches regularly - they consume storage too

Development Branch Management

Development branches are often overlooked cost centers:

• Delete unused development branches immediately after merging
• Use branch promotion instead of creating new production branches
• Limit development branch data size - they don't need full production datasets
• Implement automated branch cleanup in CI/CD pipelines

Cross-Platform Optimization Principles

Regardless of your platform choice, these universal principles apply:

Monitoring and Alerting

Set up cost monitoring before you need it, not after your first surprise bill. Each platform offers different tools:

• Supabase: Built-in usage dashboard with real-time updates
• Firebase: Google Cloud Billing alerts with budget thresholds
• PlanetScale: Third-party tools like Vantage for detailed analytics

Development Environment Optimization

Development costs often exceed production costs due to poor cleanup habits:

• Use local development databases when possible
• Implement automated resource cleanup in CI/CD pipelines
• Share development environments across team members
• Use production data samples, not full datasets, for development

Architecture-Level Cost Optimization

Sometimes the biggest savings come from architectural changes:

• Implement proper caching layers to reduce database queries
• Use read replicas for analytics workloads when available
• Consider hybrid approaches - use different platforms for different use cases
• Evaluate serverless vs. always-on based on your traffic patterns

Each platform has its own way of fucking you over cost-wise. Supabase at least tells you upfront what you're paying for and actually stops charging when you hit your limit. Firebase can be cheap if you know exactly what you're doing, but you'll spend weeks figuring out why your bill is so high and questioning your life choices. PlanetScale costs a lot but it's predictable and doesn't break in weird ways.

The key is understanding how each platform's billing works so you can optimize for it instead of getting surprised by weird charges that make you want to rage-quit development.

The Firebase Bill That Made Me Question Everything

Last year I helped a team debug an $8,200 monthly Firebase bill. Their notification system was reading documents everywhere - a user liking a post would somehow trigger 40+ database operations. What the actual fuck.

They'd built everything with real-time listeners because it seemed fancy, but Firebase charges for every single document read triggered by those listeners. Including the ones you don't expect and definitely didn't ask for.

Took about a month of tracing through Firebase analytics to figure out where the money was going. Their entire app was designed like the database was free and local instead of metered and remote.

Architectural Anti-Patterns That Destroy Budgets

The Real-Time Cascade Effect (Firebase)

The Problem: Real-time listeners that trigger other real-time listeners create cascading cost explosions. Each user action triggers multiple onSnapshot() subscriptions, each generating document reads, each triggering more subscriptions.

What was happening: User likes a post → updates the post → notifies all followers → updates everyone's feed → recalculates engagement scores. One button click somehow became 35 document reads.

With 50 test users this seemed fine. With 10,000 active users it was a financial disaster.

The Fix: Implement event-driven architecture using Cloud Functions for background processing. Batch updates using Firestore transactions to reduce read operations by 60-80%.

// Expensive: Multiple real-time listeners (this killed our budget)
onSnapshot(postRef, (post) => {
  updateUserFeed(post);        // triggers 5+ reads
  notifyFollowers(post);       // triggers 20+ reads per follower
  updateEngagementMetrics(post); // another 3-4 reads
  // One like = 35+ document reads. Absolute genius architecture.
});

// Fixed: Single listener + background processing
onSnapshot(postRef, (post) => {
  updateUI(post);  // Just update what users actually see
  // Let functions handle the expensive bullshit async
  queueBackgroundUpdate('post-updated', post.id);
});

The Connection Pool Illusion (Supabase)

The Problem: Teams assume Supabase's connection pooling eliminates all connection-related costs. But poorly designed database queries can still overwhelm the pool and force compute upgrades.

Real Example: E-commerce team built their admin dashboard to refresh analytics every second. Peak traffic meant 50+ concurrent analytical queries running constantly. Supavisor kept the connections stable, but CPU usage spiked so hard they had to upgrade from Small ($40/month) to Large ($160/month) compute just to keep the admin panel working.

The Fix: Separate analytical workloads using read replicas and implement query result materialization for expensive aggregations. Reduced compute costs by 65% while improving performance.

The Development Branch Proliferation (PlanetScale)

The Problem: Database branching is PlanetScale's killer feature, but unmanaged branches become storage cost sinkholes. Each branch stores full data copies, and teams create branches for every feature, bug fix, and experiment.

What I've seen: Team with 30+ dev branches because their workflow was "branch for every feature, clean up never." Each branch stored their entire production dataset - about 25GB. Brilliant strategy.

$37.50 per branch times 30 branches = over $1,100/month for development data that nobody was actively using. Fucking ouch.

The Fix: Implement automated branch lifecycle management:

• Auto-delete branches after PR merge
• Use shared staging branches for multiple features
• Implement data sampling for development (10% of production data)
• Set up branch usage monitoring

Automated branch cleanup brought their storage costs from $1,100+ down to about $180/month. Took an afternoon to set up the GitHub Action.

Platform-Specific Advanced Optimizations

Supabase: The PostgreSQL Performance Multiplier

Moving beyond basic Supabase optimization requires leveraging PostgreSQL's advanced features that most teams ignore.

Materialized Views for Analytics
Instead of running expensive aggregation queries repeatedly, use materialized views to pre-calculate results:

-- Expensive: Recalculated on every dashboard load
SELECT user_id, COUNT(*) as order_count, SUM(total) as total_spent
FROM orders 
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY user_id;

-- Optimized: Materialized view updated once per hour
CREATE MATERIALIZED VIEW user_stats_30d AS
SELECT user_id, COUNT(*) as order_count, SUM(total) as total_spent
FROM orders 
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY user_id;

Partial Indexes for Sparse Data
Most applications have data where only a small percentage of rows match common query patterns. Partial indexes dramatically reduce storage costs and improve query performance:

-- Standard index: Indexes all orders (including 95% completed orders)
CREATE INDEX idx_orders_status ON orders(status);

-- Partial index: Only indexes pending/processing orders (5% of data)
CREATE INDEX idx_orders_pending ON orders(status) 
WHERE status IN ('pending', 'processing');

Row Level Security (RLS) Query Optimization
Row Level Security is essential for multi-tenant applications, but poorly designed RLS policies create query performance disasters:

-- Expensive: RLS policy scans entire table
CREATE POLICY tenant_isolation ON orders
FOR ALL TO authenticated
USING (tenant_id = auth.jwt() ->> 'tenant_id');

-- Optimized: RLS with proper indexing
CREATE INDEX idx_orders_tenant_created ON orders(tenant_id, created_at);
CREATE POLICY tenant_isolation ON orders
FOR ALL TO authenticated  
USING (tenant_id = auth.jwt() ->> 'tenant_id');

Firebase: Operation-Level Cost Engineering

The key to Firebase cost optimization is understanding that every operation has multiple cost dimensions: reads, writes, storage, bandwidth, and compute time.

Firestore Composite Index Strategy
Most teams create too many indexes or the wrong indexes. Composite indexes should align with your actual query patterns, not theoretical future needs:

// Instead of multiple single-field queries (expensive)
const posts = await db.collection('posts').where('status', '==', 'published').get();
const authorPosts = await db.collection('posts').where('author', '==', userId).get();

// Use composite queries (cheaper)
const posts = await db.collection('posts')
  .where('status', '==', 'published')
  .where('author', '==', userId)
  .get();

Cloud Functions Cold Start Optimization
Cold start costs can consume 40-60% of your Functions budget. Optimization strategies:

// Expensive: Initializing everything on every call (dumb but common as hell)
exports.processOrder = functions.https.onCall((data) => {
  const stripe = require('stripe')(process.env.STRIPE_KEY); // slow as fuck
  const nodemailer = require('nodemailer');                 // also slow
  // Each call pays cold start penalty for these. Smart.
});

// Fixed: Initialize once, reuse everywhere
const stripe = require('stripe')(process.env.STRIPE_KEY);
const nodemailer = require('nodemailer');

exports.processOrder = functions.https.onCall((data) => {
  // Just use the already-initialized clients
  // Cut cold start costs by ~60% with this one simple trick
});

Firestore Bundle Loading
Firestore bundles pre-package commonly accessed data, reducing document reads by 50-80% for new users:

// Expensive: Individual document reads for app initialization  
const user = await db.collection('users').doc(userId).get();
const settings = await db.collection('settings').doc('app').get();
const features = await db.collection('features').where('enabled', '==', true).get();

// Optimized: Bundle loading
const bundle = await fetch(`/api/user-bundle/${userId}`);
await db.loadBundle(bundle);
// All data now cached locally, subsequent queries don't trigger reads

PlanetScale: Vitess-Level Optimizations

PlanetScale runs on Vitess, which enables advanced optimizations that aren't available in traditional MySQL.

Query Routing Optimization
Vitess automatically routes queries to appropriate shards, but poorly designed queries can force expensive cross-shard operations:

-- Expensive: Cross-shard query
SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at > '2023-01-01'
GROUP BY u.id;

-- Optimized: Shard-aware query design
-- Store denormalized order counts in users table
SELECT name, order_count FROM users 
WHERE created_at > '2023-01-01';

Vstream Change Data Capture
Instead of polling for changes (expensive), use VStream for real-time change data capture:

// Expensive: Polling for changes
setInterval(async () => {
  const changes = await db.query('SELECT * FROM orders WHERE updated_at > ?', [lastCheck]);
  processChanges(changes);
}, 5000);

// Optimized: VStream change capture
const stream = planetscale.createChangeStream({
  keyspace: 'ecommerce',
  shard: '-',
  gtid: lastPosition
});

stream.on('change', (change) => {
  processChange(change);
});

Schema Migration Cost Optimization
Zero-downtime migrations consume compute resources during deployment. Optimize large migrations:

-- Expensive: Single large migration
ALTER TABLE orders ADD COLUMN priority INT DEFAULT 1;
UPDATE orders SET priority = CASE 
  WHEN total > 1000 THEN 3
  WHEN total > 100 THEN 2
  ELSE 1
END;

-- Optimized: Batched migration with backfill strategy
-- 1. Add column with default
ALTER TABLE orders ADD COLUMN priority INT DEFAULT 1;
-- 2. Background job updates priority in batches
-- 3. Separate migration makes column NOT NULL after backfill

Multi-Platform Cost Arbitrage

The most sophisticated teams use different platforms for different use cases, optimizing for each platform's strengths:

Hybrid Architecture Example

• PlanetScale: Transactional data (orders, payments, user accounts)
• Supabase: User-facing features (auth, real-time chat, file uploads)
• Firebase: Analytics and messaging (push notifications, A/B testing)

Cost Benefits:

• PlanetScale's zero-downtime migrations for critical business data
• Supabase's cost controls for user-generated content and real-time features
• Firebase's analytics integration without paying Firebase database costs

Implementation Strategy:

1. Start with single platform for MVP
2. Identify cost/performance bottlenecks at scale
3. Migrate specific use cases to optimal platforms
4. Implement cross-platform data synchronization where needed

The ROI of Advanced Optimization

From what I've seen helping teams with this shit:

Time Investment: 40-120 hours of senior eng time (mostly debugging why things broke)
Typical Savings: $2k-15k/month recurring
Payback Period: 1-3 months if you don't fuck it up completely
Success Rate: Most teams get 50%+ cost reduction (if they actually finish and don't give up)

Don't bother with advanced optimization unless:

• Under $1,000/month: Just focus on growth, not premature optimization
• $1,000-5,000/month: Advanced single-platform stuff starts making sense
• Above $5,000/month: Multi-platform strategies worth the complexity headache

Look: fixing architecture problems saves way more money than tweaking queries, but it takes real expertise and weeks of debugging. You'll probably break something along the way and question your career choices.

These optimizations usually make your app faster and more reliable too - the cost savings are just a nice bonus after you stop cursing at error logs and want to throw your computer out the window.

Anyway, if you're ready to dive into this optimization hellscape, you'll need the right tools and resources. Here's the shit that'll actually help...