VibeWeek
Home/Grow/Database Sharding & Partitioning: When You Actually Need It, How to Do It Without Regret, and What to Try First

Database Sharding & Partitioning: When You Actually Need It, How to Do It Without Regret, and What to Try First

⬅️ Day 6: Grow Overview

If you're running a SaaS in 2026 and someone says "we should shard the database," the right response is "let me push back hard before we commit." Sharding is one of the most regrettable architectural decisions teams make — usually adopted too early (when vertical scaling, read replicas, partitioning, or schema redesign would have worked) and almost always under-estimated for operational complexity. Most indie SaaS that "shard at $5M ARR" are solving symptoms instead of root causes.

A working sharding / partitioning decision answers: what scale problem are we actually solving, what alternatives have we exhausted, what shard key won't bite us in 3 years, and how does our operational maturity map to multi-shard reality. Done well, sharding unblocks 10-100x scale. Done badly, it consumes a quarter of engineering capacity for years and produces a system everyone hates.

This guide is the playbook for thinking about sharding and partitioning honestly — when to defer, when to adopt, what alternatives to try first, and how to ship without inheriting a decade of distributed-systems pain. Companion to Database Indexing Strategy, Performance Optimization, and Multi-Tenancy.

Defer Sharding as Long as Possible

The first lesson: most teams that think they need sharding don't. Push back; exhaust alternatives.

Help me decide if I actually need to shard.

The honest hierarchy of scaling Postgres (or MySQL):

**1. Vertical scaling** (try first; 90% of indie SaaS stop here)

- Bigger machine: more RAM, more CPU, faster disk
- Modern Postgres on AWS RDS / Google Cloud SQL / Neon / Supabase scales to 96 vCPU + 768 GB RAM
- Cost: linear with hardware; predictable
- Engineering cost: nearly zero (instance resize)
- Sustains: 10K-50K writes/sec; multi-TB databases

**2. Read replicas** (next; 70% of teams that thought they needed sharding stop here)

- Routes read traffic to replicas (1-5 replicas typical)
- Origin handles writes
- Postgres native; managed by RDS / Neon / Supabase
- Cost: 50-100% per replica
- Engineering cost: read/write split in app code

**3. Connection pooling** (often missed; cheap win)

- PgBouncer / Postgres-built-in pooling
- Reduces connection-overhead bottleneck
- Cost: ~zero (often bundled)
- Engineering cost: minimal config

**4. Caching** (per [caching-strategies-chat](caching-strategies-chat.md))

- Reduce DB load by 80-95% for hot data
- Often mistaken-as-impossible because "data must be fresh"
- Most data tolerates stale-by-seconds

**5. Schema / query optimization** (per [database-indexing-strategy-chat](database-indexing-strategy-chat.md))

- Indexing audit
- Slow-query elimination
- Denormalization where appropriate

**6. Partitioning (table-level; not sharding)** (next; covered below)

- Same database; tables split into partitions by date / tenant / range
- Postgres native (since v10)
- Engineering cost: moderate

**7. Functional / vertical partitioning** (split by domain)

- Different tables / different DBs (e.g., events table on separate DB from users)
- Each DB still vertical-scaled
- Engineering cost: high (cross-DB joins / consistency)

**8. Logical sharding** (multi-tenant: each tenant on a database)

- Each shard is a complete schema
- Routing layer maps tenant → shard
- Engineering cost: very high

**9. Horizontal sharding** (single tenant data spread across nodes)

- Most complex
- Requires re-architecting
- Engineering cost: extreme

**The rule**: each layer down adds 3-10x engineering complexity. Move down only when the layer above is exhausted.

**The "have we exhausted X?" checklist**:

Before considering sharding, prove:
- [ ] Vertical scaling: at largest available instance? Or close?
- [ ] Read replicas: in production? Saturated?
- [ ] Connection pooling: enabled?
- [ ] Caching: implemented for hot reads?
- [ ] Indexes: audited and optimized?
- [ ] Slow queries: zero in p99?
- [ ] Partitioning: considered for large tables?

If any unchecked: try it first.

For my system:
- Current scale (rows / req-per-sec / GB)
- Current hardware
- Layers tried so far
- The pain that drove the sharding consideration

Output:
1. The "where am I in the hierarchy" assessment
2. The "have we exhausted X" audit
3. The next step BEFORE sharding

The biggest unforced error: adopting sharding without exhausting cheaper options. A team at $1M ARR shards their Postgres because "Stripe shards" — except Stripe shards at $20B revenue scale, not $1M. Vertical scaling + read replicas + caching gets most indie SaaS to $20M+ ARR. The right time to shard is when you''ve exhausted those AND the math says you''ll exhaust them next quarter.

Postgres Partitioning: The Underused Middle Ground

Before sharding, partition. It''s much cheaper and Postgres-native.

Help me design Postgres partitioning.

The concept:

Partitioning splits a single LOGICAL table into multiple PHYSICAL tables on the same database. The database routes queries to relevant partitions; the application sees one table.

**Partition strategies**:

**1. Range partitioning (by date — most common)**

```sql
CREATE TABLE events (
  id BIGINT,
  tenant_id UUID,
  created_at TIMESTAMPTZ,
  payload JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_q1 PARTITION OF events
  FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');
CREATE TABLE events_2026_q2 PARTITION OF events
  FOR VALUES FROM ('2026-04-01') TO ('2026-07-01');
-- ... etc

Use for:

  • Time-series data (events, logs, audit logs)
  • Tables that grow unbounded
  • Data with retention policies (drop old partitions = fast)

2. List partitioning (by category)

CREATE TABLE orders (
  id UUID,
  region TEXT,
  ...
) PARTITION BY LIST (region);

CREATE TABLE orders_us PARTITION OF orders FOR VALUES IN ('us', 'ca');
CREATE TABLE orders_eu PARTITION OF orders FOR VALUES IN ('uk', 'de', 'fr');

Use for:

  • Geographic / regional data
  • Large multi-tenant tables (one partition per big tenant)

3. Hash partitioning (even distribution)

CREATE TABLE messages (
  id UUID,
  user_id UUID,
  ...
) PARTITION BY HASH (user_id);

CREATE TABLE messages_p0 PARTITION OF messages FOR VALUES WITH (MODULUS 4, REMAINDER 0);
-- ... 4 partitions

Use for:

  • Even distribution of writes
  • When range / list don''t fit naturally

Benefits of partitioning:

  • Query performance: partition pruning ignores irrelevant partitions
  • Vacuum / analyze: per-partition; faster
  • Drop old data: DROP TABLE events_2025_q1 is instant (no DELETE needed)
  • Index size: per-partition indexes; smaller; fit in cache
  • Maintenance: rebuild one partition at a time

When partitioning helps:

  • Tables > 100M rows
  • Tables with clear time-or-category boundaries
  • Append-only tables (events, logs, audit)
  • Tables with large historical data + active recent data

When partitioning doesn''t help:

  • Tables < 10M rows (overhead > benefit)
  • No natural partition key
  • Random-access patterns across all rows

The "live partitioning" trap:

If you partition by tenant_id for multi-tenant SaaS:

  • Pro: queries scoped to single tenant are very fast
  • Con: cross-tenant queries (admin reports) hit all partitions
  • Con: tenant skew (one giant tenant = one giant partition)

For most multi-tenant SaaS: partition by date if anything; tenant_id stays as an indexed column.

Operations:

  • New partitions: create proactively (don''t wait for a row to land in non-existent partition)
  • Old partitions: drop on retention boundary
  • pg_partman extension: automates new + old partitions

Common partitioning targets:

  • events table (range by month/quarter)
  • audit_logs (range by month)
  • messages / notifications (range by month)
  • metrics / analytics_events (range by day/week)

For my system:

  • Tables that exceed 100M rows
  • Their natural partition key
  • The retention policy

Output:

  1. The partition-candidates list
  2. The partition strategy per table
  3. The migration plan

The biggest partitioning mistake: **partitioning the wrong table.** A 5M-row table doesn''t benefit from partitioning; the overhead exceeds the gain. Partition tables that are HUGE (100M+ rows) AND have a natural boundary (time, region, category). Other tables stay un-partitioned.

## When Sharding Becomes Real

After all alternatives, sometimes sharding is the answer. Know the signals.

Help me identify the real sharding triggers.

Real signals to shard:

1. Vertical scaling has plateaued

  • You''re on the largest available DB instance
  • Cost-per-request is climbing
  • Adding RAM / CPU is marginal improvement

2. Single-server bottleneck is real

  • Single-machine I/O capacity hit
  • Network bandwidth to DB capped
  • WAL replication can''t keep up with writes

3. Geographic distribution required

  • Data sovereignty (EU customers must stay in EU)
  • Regional latency requirements (sub-100ms reads from any region)
  • Disaster-recovery isolation

4. Multi-tenant tenant-isolation needs

  • Per-tenant DB requested by enterprise customers
  • Compliance requires physical separation
  • Tenant data volumes are extreme (one tenant = TB of data)

5. Specific scale numbers

For Postgres on commodity hardware:

  • < 10TB total: vertical-scale + partition + read-replica
  • 10-100TB: partition heavily; consider sharding
  • 100TB+: sharding likely required

For write throughput:

  • < 5K writes/sec: single instance fine
  • 5-20K writes/sec: tuned single instance + replicas
  • 20K+ writes/sec: sharding consideration

These are rough; actual numbers depend on data shape, access pattern, hardware.

The "would Stripe shard at our scale?" gut check:

Stripe is ~ 100x larger than the average mid-market SaaS. They share. You probably don''t need to.

Acceptable reasons to shard:

  • Vertical scaling exhausted AND we''re growing 3x next year
  • Compliance / data residency mandates
  • Per-tenant DB strategy for enterprise

Bad reasons to shard:

  • "It''s the modern way"
  • "Twitter / Stripe / Discord shard"
  • "We might need to scale someday"
  • "Our DB feels slow" (without exhausting tuning)
  • "Engineer X just joined from a sharded company"

For my system:

  • Real scale today
  • Projected scale (12 months)
  • Specific bottlenecks observed

Output:

  1. The honest "do we need to shard" assessment
  2. The bottleneck-specific evidence
  3. The "we''re NOT going to shard, here''s why" commitment

The biggest sharding-trigger mistake: **shading because of fear of "needing to" later.** "Let''s shard now while we have time to do it right" is the rationalization for premature optimization that destroys quarters of engineering velocity. The right time to shard is when you''re actively hitting limits — not when you imagine you might.

## Pick the Shard Key — The Decision That Lives Forever

The shard key is the most consequential decision in sharding. Get it wrong; pay forever.

Help me pick the shard key.

The shard key determines:

  • How rows are distributed across shards
  • Which queries are fast (single-shard) vs slow (cross-shard / scatter-gather)
  • How easy / hard re-sharding will be later

The shard-key options:

Option A: Tenant ID (most common for multi-tenant SaaS)

  • Each tenant lives entirely on one shard
  • Every query filters by tenant_id → goes to one shard
  • Cross-tenant queries (admin reports) require scatter-gather
  • Tenant-skew risk: one huge tenant = one overloaded shard

Pros:

  • Most queries are tenant-scoped already
  • Aligns with security model (tenant isolation)
  • Operationally clean (move tenant = move data)

Cons:

  • Tenant skew (Pareto distribution)
  • Cross-tenant analytics hard
  • Re-sharding requires moving entire tenant

Option B: User ID

  • Each user''s data lives on one shard
  • Works for B2C / individual-data-heavy products
  • Skew: power-users dominate

Pros:

  • Aligns with B2C access patterns

Cons:

  • Multi-tenant joins become cross-shard
  • Query patterns may not align (user accesses data of others)

Option C: Random / Hash

  • Even distribution; no logical grouping
  • All queries fan out to all shards

Pros:

  • Even load
  • No skew

Cons:

  • Every query is scatter-gather (slow)
  • Defeats most of sharding''s benefit
  • Use only as last resort

Option D: Geographic / Region

  • US shard, EU shard, etc.
  • Aligns with data residency

Pros:

  • Compliance
  • Latency

Cons:

  • Cross-region access is slow
  • Requires data-residency discipline

The "tenant skew" problem:

In SaaS, a 90/10 distribution is common: 10% of tenants generate 90% of activity. If you shard by tenant_id with naive hashing:

  • One shard has the giant tenants
  • Other shards are nearly empty
  • Performance is determined by the busiest shard

Mitigations:

  • Manual placement: largest tenants get dedicated shards
  • Adaptive resharding: monitor and rebalance
  • Shard at tenant-group granularity: small tenants share; big tenants isolate

The "co-location" rule:

Data that''s queried together should live on the same shard.

If users and posts are joined in queries, they should share a shard key. Both partitioned by tenant_id works.

Cross-shard joins are anti-pattern.

The "globally unique IDs" issue:

After sharding, IDs from different shards must not collide.

  • UUID v4 / v7: no collision risk
  • Snowflake IDs: include shard ID
  • Auto-increment integers: NEVER (collision risk; renumber pain)

The "this is forever" reality:

Re-sharding is enormously expensive. Once you commit to a shard key, you live with it for years. Don''t pick lightly.

For my system:

  • Multi-tenant or not?
  • Tenant size distribution
  • Query patterns
  • Geographic constraints

Output:

  1. The shard-key recommendation
  2. The justification
  3. The "what if we''re wrong" plan

The biggest shard-key mistake: **optimizing for the wrong query pattern.** A SaaS that picks `user_id` as shard key when most queries are tenant-scoped ends up with cross-shard queries everywhere. Pick the shard key that matches the dominant query pattern. If queries are tenant-scoped: shard by tenant. If queries are user-scoped: shard by user. The shard key follows the access pattern.

## The Operational Reality: What Sharding Actually Costs

Sharding isn''t just a code change. The operational model shifts entirely.

Help me understand the operational cost.

What changes after sharding:

1. Application code

  • Every query needs the shard key (or scatter-gather penalty)
  • Connection pooling: per-shard pools
  • Transactions: single-shard or distributed (slow + complex)
  • ORMs: many don''t handle sharding natively

2. Schema changes

  • Migrations must run on every shard
  • Schema-skew risk during deploy
  • Add column → run on all shards (potentially serialized)

3. Backups + restore

4. Monitoring

  • Per-shard metrics
  • Aggregated view across shards
  • Imbalance alerts (one shard hot)

5. Cross-shard queries

  • Analytics dashboards: scatter-gather
  • Admin tools: harder to build
  • Reports: pre-aggregate to a separate analytics DB

6. Re-sharding

  • Ever: expensive, dangerous, multi-quarter project
  • Have an exit plan

7. Joins

  • Cross-shard joins: don''t do them in real-time
  • Co-locate joined data
  • Or accept eventual consistency via async pipelines

8. Foreign keys

  • Cross-shard FKs don''t exist; you handle integrity in code
  • Riskier; easier to leak inconsistencies

9. Distributed transactions

  • Avoid if possible
  • 2-phase commit: complex, slow
  • Saga pattern: eventual consistency
  • Most teams just don''t do them

10. Operational expertise

  • Need DBAs / SREs who understand distributed databases
  • Documentation-heavy
  • Incident response is harder

The "10x complexity" rule:

A sharded database adds ~10x operational complexity vs single instance.

If your team isn''t ready for that complexity: don''t shard.

The middleware / query-router options:

If you commit to sharding, consider:

  • Citus (now Microsoft) — Postgres extension; transparent sharding
  • Vitess — MySQL sharding (used by YouTube, Slack)
  • CockroachDB — built-in distributed; not really "sharding" in the traditional sense
  • YugabyteDB — distributed Postgres
  • PlanetScale (now Sigma) — serverless MySQL with Vitess
  • Neon branching — different shape; not sharding

Or DIY:

  • Application-level routing
  • Per-shard Postgres instances
  • More flexible; more operationally heavy

The 80/20 rule:

If you''re going to shard, use a managed solution (Citus, Vitess, CockroachDB, Yugabyte). DIY sharding is 5x more work for marginal benefit.

For my plan:

  • The team''s distributed-DB experience
  • The managed vs DIY decision
  • The cost-tolerance estimate

Output:

  1. The operational cost estimate
  2. The managed-solution choice (if going)
  3. The "we''ll never shard" alternative path

The biggest operational mistake: **underestimating the migration cost.** Going from single Postgres to sharded is typically 6-12 months of engineering for a small team. Migrations are double-write phases, dual-read phases, traffic-shift phases, cutover, and stabilization. If your team can''t spare a quarter of engineering capacity for this, find another way.

## The Modern Alternative: Cloud-Native Distributed SQL

In 2026, you have alternatives to traditional sharding. Know them.

Help me consider modern alternatives.

The cloud-native distributed-SQL category:

1. CockroachDB

  • Postgres-compatible
  • Built distributed from the ground up
  • Auto-shards under the hood
  • Strong consistency (Raft / Spanner-style)
  • Geographic distribution

Pros:

  • Avoids manual sharding
  • Survives node failures gracefully
  • Good for multi-region

Cons:

  • Slower per-query than single-instance Postgres
  • Different operational model
  • Pricing model

2. YugabyteDB

  • Similar shape to CockroachDB
  • More Postgres-compatible

Pros:

  • More Postgres feature parity
  • Open-source

Cons:

  • Smaller community than CockroachDB

3. Spanner (Google)

  • Google''s distributed SQL
  • TrueTime for global consistency
  • Enterprise-grade

Pros:

  • Battle-tested at Google scale
  • Multi-region strong consistency

Cons:

  • Google-only
  • Expensive
  • Less SQL-flexible

4. Aurora / Aurora Limitless (AWS)

  • Aurora: regional distributed Postgres / MySQL
  • Limitless: AWS''s sharded variant

Pros:

  • Tight AWS integration
  • Strong tooling

Cons:

  • AWS-only
  • Pricing climbs

5. PlanetScale / Sigma

  • MySQL with Vitess under the hood
  • Branching workflow

Pros:

  • Schema-change workflow excellent
  • Easy scaling

Cons:

  • MySQL only
  • Different operational model

6. Neon

  • Serverless Postgres with branching
  • Auto-scaling compute
  • Storage on shared layer

Pros:

  • Postgres-compatible
  • Branching like git
  • Serverless scaling

Cons:

  • Single-region writes
  • Not "sharding" in traditional sense

The "skip sharding entirely" path:

For many SaaS, the answer to "we''re hitting Postgres limits" is "switch to distributed Postgres / Aurora Limitless / CockroachDB" — not "shard ourselves."

Tradeoffs:

  • Less control / customization
  • Higher per-row cost (typically)
  • But: zero sharding ops complexity

For a startup with engineering bandwidth constraints: distributed-SQL is usually the better path.

The "build vs buy" decision:

Aspect DIY sharding Distributed SQL
Engineering effort Quarters Days-weeks
Per-row cost Lower Higher
Operational complexity High Lower
Flexibility High Lower
Battle-tested at scale Maybe Yes
Vendor lock-in Less More

Most modern SaaS: distributed SQL is the right answer.

For my system:

  • Current DB
  • Distributed-SQL options that match
  • The "switch to managed distributed" alternative

Output:

  1. The distributed-SQL alternative
  2. The cost-comparison estimate
  3. The "stay with Postgres + sharding" tradeoff

The biggest modern-alternative mistake: **building DIY sharding when CockroachDB / Aurora Limitless / similar would work.** A small team that loses 6-12 months to DIY sharding could have switched to a distributed Postgres product in 1-2 weeks. The "we want full control" rationale rarely justifies the engineering cost. Buy distributed-SQL when possible; build only when justified.

## The Pre-Sharding Checklist

If you''re going to commit, do it deliberately.

The pre-sharding checklist.

Before committing:

1. Quantify the problem

  • What scale metric is hit? (writes/sec, GB, rows)
  • What''s the current load?
  • What''s projected for 12 months?

2. Exhaust alternatives

  • Vertical scaling at max instance
  • Read replicas in production (multi)
  • Connection pooling enabled
  • Caching covers hot reads
  • Indexing audited
  • Slow queries eliminated
  • Partitioning considered

3. Research distributed-SQL

  • Have we evaluated CockroachDB / Aurora Limitless / Yugabyte / Spanner?
  • Is "switch to managed distributed" cheaper than DIY sharding?

4. Pick the shard key carefully

  • Aligned with dominant query pattern
  • Tenant-skew analyzed
  • Co-location of joined data verified
  • Globally-unique ID strategy in place

5. Decide on tooling

  • Citus / Vitess / DIY?
  • Managed vs self-host?

6. Plan the migration

  • Double-write phase
  • Dual-read phase
  • Cutover plan
  • Rollback plan

7. Operational readiness

  • DBA / SRE expertise
  • Monitoring per-shard
  • Backup / restore strategy
  • Schema-migration strategy

8. Communicate up

  • Stakeholders informed of timeline (often 2-4 quarters)
  • Engineering velocity will drop
  • Bugs will happen

9. Document the "why"

  • Why we shard:
  • Why this shard key
  • Why this tooling
  • Future decision-makers can understand

10. Set the success criteria

  • What does "done" look like?
  • What latency targets must be met?
  • What backup-restore timing must be achieved?

The "do we still want to do this?" gate:

After completing the checklist, re-ask:

  • Is this still worth the cost?
  • Has the urgency changed?
  • Has a vendor / product made this unnecessary?

If the answer is "yes, proceed": do it deliberately. If the answer is "no, pause": pause.

For my plan:

  • Checklist completion
  • The honest go / no-go

Output:

  1. The checklist
  2. The committed go / no-go
  3. The next-step plan

The biggest pre-sharding mistake: **starting the project without honest stakeholder alignment.** Engineering decides to shard; founder doesn''t realize the velocity cost; sales pushes new features anyway; everyone is angry by month 6. Sharding decisions are company-wide; align before starting.

## Avoid Common Pitfalls

Recognizable failure patterns.

The sharding mistake checklist.

Mistake 1: Sharding too early

  • $1M ARR, vertical scaling barely tried
  • Fix: exhaust hierarchy first

Mistake 2: Wrong shard key

  • Random / user_id when tenant_id was right
  • Fix: align with dominant query pattern; analyze first

Mistake 3: DIY when managed-distributed exists

  • 12-month sharding project; could have switched DBs
  • Fix: evaluate CockroachDB / Aurora / etc.

Mistake 4: Auto-increment IDs across shards

  • Collisions; renumbering pain
  • Fix: UUIDs / Snowflake / sharded sequence

Mistake 5: Cross-shard joins in real-time

  • Hot path scattered across shards
  • Fix: co-locate; or async aggregation

Mistake 6: Cross-shard distributed transactions

  • Slow; complex; still might fail
  • Fix: design for single-shard transactions; sagas for cross-shard

Mistake 7: Per-tenant skew ignored

  • One giant tenant overwhelms one shard
  • Fix: monitor; rebalance; isolated shards for largest tenants

Mistake 8: Migrations rolled out unevenly

  • Schema skew during deploy
  • Fix: run migrations on all shards atomically

Mistake 9: Backup strategy unaccounted

  • Per-shard backups not coordinated
  • Fix: test full restore quarterly

Mistake 10: Sharding before partitioning

  • Skipped the easier middle step
  • Fix: try table-level partitioning first

The quality checklist:

  • Vertical / replica / cache / partition tried first
  • Distributed-SQL evaluated
  • Shard key aligned with queries
  • No cross-shard transactions in hot path
  • Co-located data co-sharded
  • UUIDs or sharded IDs (not auto-increment)
  • Migration strategy tested
  • Per-shard monitoring
  • Backup / restore tested
  • Team trained on operational model

For my plan:

  • Audit
  • Top 3 fixes

Output:

  1. Audit
  2. Fixes prioritized
  3. The committed plan

The single most-common mistake: **picking sharding because it sounds advanced.** Engineering teams sometimes treat sharding as a maturity badge. It isn''t. Sharding is the option of last resort because it adds permanent operational tax. The right move 90% of the time: don''t shard. Vertical scale, optimize, partition, switch to distributed-SQL. Saving 6 months of sharding work funds 6 months of feature shipping.

---

## What "Done" Looks Like

A working scaling-strategy in 2026 has:

- The hierarchy followed (vertical → replica → cache → partition before sharding)
- If sharded: shard key aligned with dominant query pattern
- No DIY sharding when distributed-SQL alternative exists at acceptable cost
- Per-shard monitoring + backups + schema-migration strategy
- Globally-unique IDs (UUID / Snowflake)
- Co-located data co-sharded
- Pre-aggregated analytics for cross-shard reporting
- Documented decision: why this approach was chosen

The hidden cost of premature sharding: **engineering capacity vaporized for years.** Teams that shard too early spend 30-50% of engineering on database-operations work that produces no customer-visible value. The product slows. Competitors ship. The architecture decision becomes the company''s biggest constraint. Defer sharding aggressively; exhaust alternatives; switch to distributed-SQL when possible; only DIY-shard when truly necessary and team capacity exists.

## See Also

- [Database Indexing Strategy](database-indexing-strategy-chat.md) — index before considering sharding
- [Database Migrations](database-migrations-chat.md) — schema changes across shards
- [Multi-Tenancy](multi-tenancy-chat.md) — tenant-isolation drives sharding decisions
- [Caching Strategies](caching-strategies-chat.md) — try before sharding
- [Performance Optimization](performance-optimization-chat.md) — broader perf
- [Backups & Disaster Recovery](backups-disaster-recovery-chat.md) — across shards
- [Audit Logs](audit-logs-chat.md) — natural partitioning candidate
- [Real-Time Collaboration](real-time-collaboration-chat.md) — cross-shard challenges
- [Service Level Agreements](service-level-agreements-chat.md) — uptime impacts
- [VibeReference: Database Providers](https://www.vibereference.com/backend-and-data/database-providers) — Postgres / Citus / CockroachDB / etc.
- [VibeReference: Postgres](https://www.vibereference.com/backend-and-data/postgres) — Postgres deep-dive
- [VibeReference: SQL](https://www.vibereference.com/backend-and-data/sql) — SQL fundamentals
- [VibeReference: Supabase](https://www.vibereference.com/backend-and-data/supabase) — managed Postgres
- [VibeReference: Convex](https://www.vibereference.com/backend-and-data/convex) — alternative model

[⬅️ Day 6: Grow Overview](README.md)