# Supabase — When to use Read Replicas vs. bigger compute

- Company: Supabase (supabase.com)
- Announced: 2026-01-15
- Category: not stated
- Coverage: not counted
- Announcement: no
- Group: routine
- Source: https://supabase.com/blog/read-replicas-vs-bigger-compute
- Record: https://forck.live/items/21308-when-to-use-read-replicas-vs-bigger-compute
- Subject: Supabase

When your database starts slowing down, you face a choice: make your existing database bigger, or spread the load across multiple databases. Both approaches work. Neither is universally correct. The right answer depends on your workload, your budget, and where the bottleneck actually is. This post walks through how to diagnose what is causing your database to slow down, when vertical scaling (bigger compute) makes sense, when horizontal read scaling (Read Replicas) is the better path, and how to make the decision with real numbers. The scaling decision every growing database faces # Your Supabase project starts on a Small compute instance. It handles your MVP, your beta users, and your first paying customers. Then, traffic grows and response times creep up. You need to scale. Here is the quick version: The rest of this post explains how to diagnose your specific situation and make the right call with real numbers. First, diagnose the actual problem # Before choosing a scaling strategy, figure out what is actually causing the slowdown. Throwing hardware at the wrong problem wastes money. The database performance guide covers diagnostics in depth. Here are the essentials. …

---

Record: https://forck.live/items/21308-when-to-use-read-replicas-vs-bigger-compute
Catalogue: https://forck.live/llms.txt
Current issue: https://forck.live/feed.md