Recommendation

Do not shard yet. Scale vertically now—but don’t blindly buy the biggest instance. Move up one or two sizes to restore headroom, then determine what is actually consuming CPU.

At 80% CPU during peaks, you have a capacity warning, not evidence that a single Postgres writer has reached its limit. Sharding primarily solves sustained write-throughput or storage limits; it is usually the wrong remedy for expensive queries, read load, connection pressure, or poor indexing. Read bottlenecks are better handled with query tuning, caching, and replicas, while vertical scaling adds capacity without architectural change patotski.com.

For a 10-person team, sharding’s ongoing engineering and operational cost is particularly significant.

What to do now

1. Resize immediately

   • Price the next two instance sizes and choose one that brings peak utilization comfortably below roughly 50–60%.
   • Don’t jump automatically to the largest available instance; buy enough headroom for your expected 6–12-month growth.
   • Set alerts for sustained CPU, not momentary spikes.

2. Spend one focused week diagnosing the peak Use pg_stat_statements and infrastructure metrics to establish:

   • Which queries consume the most total execution time and CPU
   • Read versus write workload
   • Disk I/O and cache-hit rate
   • Lock contention and long transactions
   • Connection counts and pooling effectiveness
   • Table/index growth and unused or missing indexes
   • Whether background jobs, analytics, or backups coincide with peaks

   A high connection count can create context-switching and memory overhead before raw CPU capacity is truly exhausted, so add or tune PgBouncer if appropriate patotski.com.

3. Apply the remedy matching the bottleneck

   • Expensive reads: tune queries/indexes, cache hot results, add read replicas.
   • Analytics/reporting: move it to a replica or analytical store.
   • Connection pressure: use pooling and control concurrency.
   • One oversized table: consider native Postgres partitioning or archival.
   • Write amplification: remove redundant indexes, batch writes, and reduce avoidable updates.
   • Availability risk: if “single instance” also means no standby, prioritize managed failover, tested backups, PITR, and restore drills. Sharding is not a substitute for high availability.

This ordering—replicas/cache, vertical scaling, then sharding only when writes or capacity genuinely exceed one node—is the usual safer progression semicolony.dev.

Define explicit triggers for sharding

Revisit sharding when all of the following are true:

• The bottleneck is specifically sustained write throughput, not reads or inefficient queries.
• The primary remains saturated after tuning, batching, pruning indexes, and scaling to the largest economically sensible instance.
• Forecasted growth indicates a single node will be inadequate within about 12 months.
• Your workload has a viable shard key—typically account_id or tenant_id—that appears in nearly every important query and distributes load reasonably evenly.
• You have accepted the cost of cross-shard queries, resharding, distributed transactions, backups, migrations, and multiplied operational work.

Other valid triggers are a dataset that can no longer reasonably fit on one host, or authoritative writes that require regional ownership for latency. Those are much stronger signals than 80% CPU semicolony.dev.

Prepare without sharding

You can preserve the option cheaply:

• Make tenant/account ownership explicit in schemas and APIs.
• Ensure tenant-scoped queries include the tenant key.
• Avoid unnecessary cross-tenant transactions.
• Track per-tenant data volume and write rates to identify potential hot tenants.
• Document how global reports and uniqueness constraints would work after sharding.
• Load-test quarterly against projected growth.

Bottom line: side with vertical scaling for now, but make it a measured capacity plan rather than “buy the biggest box and forget it.” Resize, diagnose, improve availability, and agree in advance on objective sharding triggers. That avoids both a near-term incident and a premature distributed-database project.

Buy the bigger instance — but that's the third thing you should do, not the first. And to be direct: sharding a 10-person startup's Postgres at 80% peak CPU is almost certainly a mistake. Here's the reasoning.

Why not shard

Sharding is not "paying down complexity early" — it's a permanent tax on everything you build afterward. Cross-shard joins, distributed transactions, rebalancing, fan-out queries, migrations across shards, backup/restore coordination. For a 10-person team, that tax can easily consume 1–2 engineers indefinitely. Worse, sharding forces you to pick a shard key now, when your product (and therefore your access patterns) will likely look different in 18 months. Startups that shard early often shard on the wrong key and end up doing the painful migration anyway — just twice.

The "before it's an emergency" framing also assumes vertical scaling runs out soon. It doesn't. Your headroom is enormous: current-generation instances go far beyond what most startups ever need — Graviton4-based R8g instances go up to 48xlarge with an 8:1 memory-to-vCPU ratio, offering up to 192 vCPUs, 50 Gbps networking, and 40 Gbps of EBS bandwidth, and Intel-based M7i/R7i similarly max out at 48xlarge, 50% more vCPU and memory than the prior generation's maximum. If you're on anything smaller than a ~32 vCPU box today, you have multiple doublings left before vertical scaling is exhausted. Each doubling probably buys you a year or more.

What to actually do, in order

1. Diagnose before spending anything. 80% CPU at peak is a symptom, not a diagnosis. At startup scale, it's very often not "too much load" but:

• A handful of bad queries (missing indexes, N+1s, sequential scans). Turn on pg_stat_statements and look at the top 10 by total time. It's common to find 80% of CPU coming from 2–3 queries fixable in an afternoon.
• Connection overhead. If you don't have PgBouncer (or RDS Proxy) in front, hundreds of direct connections burn CPU on nothing. This is a one-day fix.
• Missing caching. If the same hot reads hammer the DB every request, a small Redis layer or even application-level caching can cut load dramatically.

2. Offload reads. If after tuning you're still CPU-bound and the load is read-heavy (it usually is), add a read replica and route analytics/dashboards/reporting there. This is operationally trivial compared to sharding and often removes the worst spiky load. If BI queries are hitting your primary, get them off today.

3. Then scale up. Once you know the workload is legitimately large rather than inefficient, upgrade the instance. Upgrading to a newer instance generation is a simple instance type modification — minutes of work versus months for sharding. Note that newer generations aren't just bigger, they're faster per core: Graviton4 instances provide up to 40% performance improvement and up to 29% better price/performance over the previous generation, so even a same-size migration to current hardware may buy meaningful headroom.

4. Do the cheap prep work for horizontal scaling — without sharding. This is the honest concession to the pro-sharding camp: their instinct that you shouldn't wait for an emergency is right, their solution is wrong. Instead:

• Make sure every large table has a tenant/customer ID column and that queries filter on it. This keeps a future shard key viable.
• Avoid features that make sharding harder (cross-tenant joins in hot paths, global sequences you depend on).
• Consider table partitioning within the single instance — it addresses some pain (index bloat, vacuum times) with a fraction of the complexity.

The one caveat

If your growth is genuinely explosive — say load is doubling every 2–3 months and you're already on a large instance — then the math changes, because you'd exhaust vertical headroom within a year and sharding takes months to do well. In that case, look first at managed distributed-Postgres options (Citus, Aurora, or similar) before hand-rolling shards, since they preserve most Postgres semantics.

But for the typical startup at your size: tune, pool, replicate, then buy the big box, and revisit sharding when you're a 40-person company with real evidence about your access patterns. You'll make a far better sharding decision then — if you ever need to make it at all.

For a 10-person startup, the engineering consensus is almost universally on the side of the scale-up (vertical scaling) camp.

Buy the bigger instance. Delay sharding for as long as humanly possible.

Here is a breakdown of why this is the right move for your startup, and the exact playbook you should follow.

The Problem with Sharding at Your Size

Sharding is not just an infrastructure change; it is an application architecture change. If you shard, your engineering team must now solve for:

• Routing: Modifying the application layer to know which shard holds which data.
• Cross-Shard Joins: You can no longer easily JOIN across tables if the data lives on different servers. You have to do this in application memory.
• Schema Migrations: Running ALTER TABLE across multiple distributed databases safely.
• Backups and Consistency: Ensuring point-in-time recovery across multiple independent machines.

For a 10-person startup, engineering bandwidth is your scarcest and most valuable resource. Sharding will permanently tax your team's velocity and essentially require 1 or 2 of your engineers to become full-time database infrastructure engineers. If you can buy your way out of this complexity, you should.

The Reality of Vertical Scaling

Ten years ago, you had to shard earlier because hardware ceilings were lower. Today, cloud providers offer massive boundaries for vertical scaling.

• AWS RDS and Aurora offer instances with up to 128 vCPUs and 4 TB of RAM.
• GCP Cloud SQL offers instances with up to 96 vCPUs and 624 GB of RAM.

If you are not currently hitting the absolute maximum limits of what your cloud provider offers, vertical scaling will buy you months—if not years—of runway with zero changes to your application code.

The Playbook: What You Should Do Next

Since you can afford either option, here is the most pragmatic step-by-step approach:

1. Immediately scale up the instance (The Quick Fix)

Double or quadruple your instance size during your next maintenance window. This immediately drops your CPU utilization from 80% down to a safe margin (e.g., 20-40%). This puts out the fire and buys you time.

2. Check your Connection Pooling (CPU Killer #1)

PostgreSQL handles connections by forking a dedicated OS process for every single client connection. If your app is opening hundreds or thousands of idle connections, the context-switching alone will max out your CPU. If you aren't using a connection pooler like PgBouncer or RDS Proxy, implement one immediately. This often slashes CPU usage by half.

3. Find missing indexes and N+1 queries (CPU Killer #2)

High CPU on Postgres is rarely caused by sheer traffic volume in a startup; it's usually caused by the database doing too much math (like sequentially scanning large tables because an index is missing). Turn on pg_stat_statements, find the top 5 most expensive queries, and optimize them.

4. Offload reads to Replicas (The Middle Ground)

If your application is read-heavy (like most web applications), you don't need to shard to scale horizontally. You can spin up Read Replicas. Point your heavy analytical queries, dashboards, and safe user-reads to the replica. Keep all writes and strict-consistency reads on the primary instance. This scales you out without the complexity of sharding.

5. Implement Caching

If aggressive database reads are spiking your CPU, put heavily accessed, rarely modified data into Redis or Memcached.

When should you shard?

You should only begin the conversation about sharding when:

1. You are running on the absolute largest hardware instance your cloud provider offers...
2. ...AND you have optimized your slow queries...
3. ...AND you have pushed all possible read traffic to replicas...
4. ...AND your database CPU or write-throughput is still maxing out.

Until you hit that wall, your engineers should be focused on building your product, not reinventing database infrastructure. Buy the biggest boat.

Claude is right if 80% is merely a healthy peak with stable latency; Gemini is right** if the database is already approaching an observable capacity cliff**. CPU percentage alone does not decide it. In one illustrative load test, 78% CPU still had zero errors, while latency and errors deteriorated sharply above 90%; the exact thresholds are workload-specific, but it demonstrates why utilization must be paired with service-level signals besthub.dev.

Minimum evidence for resizing immediately

I would resize before completing a deeper diagnosis if a short, roughly 30–60 minute validation establishes:

1. The condition is sustained and recurring

   • Database CPU remains around 80% for meaningful intervals, not just seconds.
   • Peaks are becoming longer or higher week over week.

2. There is evidence of diminishing headroom

   • P95/P99 database or request latency rises with CPU.
   • Run queues, active sessions, or connection waits accumulate.
   • Throughput stops scaling proportionally, or timeouts/errors begin appearing.
   • An upcoming launch, migration, or traffic event will increase load before tuning can safely be completed.

3. More CPU is plausibly useful

   • The primary constraint is not obviously locks, storage latency, exhausted IOPS, a full connection pool, or one serialized query.
   • CPU consumption is attributable to Postgres rather than another process or misleading host metrics.

4. The resize is a low-risk, reversible operation

   • The provider supports the target class and storage configuration.
   • You know the expected interruption or failover behavior.
   • Backups/PITR are current, and rollback to the old class is documented.
   • Any standby can keep up, and quotas/capacity are confirmed.

If latency is stable, errors are absent, CPU peaks are brief, and there is no near-term traffic event, I would concede Claude’s ordering: diagnose first, but time-box it to a day—not a multiweek performance project. At 80%, there is enough warning to investigate, but not enough evidence to declare an emergency.

One size, two sizes, or maximum?

Normally one size. Never the maximum on the evidence given.

Use a simple first-pass estimate:

At 80% utilization:

• Targeting 60% requires about 1.33× current effective CPU capacity.
• Targeting 50% requires about 1.6×.
• If instance classes double between sizes, one size up would theoretically bring comparable workload to approximately 40%, before accounting for scaling inefficiencies.

Choose two sizes up only if at least one of these is demonstrated:

• Traffic is likely to grow roughly 2× before the next safe maintenance window.
• Load testing shows one size still breaches the latency or utilization objective.
• The next size has materially inferior CPU, memory, I/O, or network characteristics for this workload.
• A resize requires significant coordination or downtime, making another near-term resize unusually costly.
• You need temporary capacity for a known launch and can later scale down.

“Buy the biggest boat” is therefore unjustified. It can mask inefficient queries, increase cost and failure blast radius, and provides no information about when the real capacity boundary will arrive. Even sharded systems require workload-specific benchmarking rather than relying on generic sizing rules; the same principle applies to vertical sizing github.com.

Validate immediately after the change

Before resizing, record CPU, throughput, P95/P99 latency, errors, active connections, I/O latency, replica lag, and the top queries. Afterward:

• Compare the same workload window against that baseline.
• Confirm latency improved and CPU fell as expected.
• Verify connection pooling and all application paths.
• Check replica lag and read-replica routing.
• Exercise or verify failover behavior.
• Keep a rollback threshold—for example, unexpected latency regression, parameter incompatibility, or persistent replication lag.

So the decision is: one size up immediately if sustained CPU correlates with deteriorating service or imminent load; otherwise perform a short diagnosis first. Move two sizes only with measured growth or load-test evidence, and do not jump to the maximum.

Conceding the ordering point

Sol and Gemini are right and I was wrong on sequencing. "Diagnose before spending anything" optimizes for cost-efficiency; at 80% peak CPU with money available, you should optimize for safety margin. A resize is a maintenance-window operation, it's reversible, and it converts a fragile situation into a calm one in which the diagnosis can happen without an incident clock ticking. Resize first, then diagnose — the diagnosis still matters just as much, because if the root cause is a bad query or connection storm, the bigger box only postpones the same cliff.

I hold one line against Gemini: not "the biggest boat." Jump one or two sizes, not to the maximum. If you go straight to the ceiling and CPU creeps back up, you've burned your last easy lever and you've lost the signal about how fast you're actually growing. Keep a doubling in reserve as your emergency brake.

The conditions that invalidate "a year of runway"

The coordinator is correct that my "each doubling buys a year" claim was asserted without measurements. So here's the actual test, which your team can run this week.

The runway formula: Runway ≈ (remaining effective doublings) × (months per demand doubling). Sharding done carefully by a small team takes roughly 6–12 months. So the trigger condition is:

Shard now if: remaining doublings × doubling period < ~12–18 months.

The inputs, concretely:

1. How many doublings do you actually have left? Count from your current instance to your provider's ceiling (~192 vCPUs on AWS, ~96–128 on GCP Cloud SQL) — then discount. Postgres does not scale linearly with cores at the high end: lock contention, WAL serialization on a single writer, buffer-partition contention, and NUMA effects mean a 2× box often yields ~1.5–1.7× real throughput past ~32–64 cores. Practical rule: count each doubling above 64 vCPUs as ~0.7 of a doubling.

• On a 4–16 vCPU instance today: 4–5 effective doublings left. Vertical scaling almost certainly wins.
• On 64+ vCPUs already: maybe 1–1.5 effective doublings. Now the growth rate matters enormously.

2. How fast is demand doubling? Pull 6 months of peak-CPU history (normalized per vCPU if you've resized). Fit the trend.

• Doubling every 9–12+ months (typical healthy startup): even from a 64-vCPU box you have ~18+ months. Don't shard.
• Doubling every 2–3 months (genuine hypergrowth): 4–5 doublings needed per year. Even from a small instance you exhaust the ceiling in 12–18 months, which is exactly one sharding project's duration. This is the case where "start before it's an emergency" is correct, and the pro-sharding half of your team wins the argument — with data, not vibes.

3. Is the load write-dominated? This is the multiplier on everything above. Check pg_stat_statements: if >50% of total execution time is INSERT/UPDATE/DELETE and WAL throughput is climbing in step with traffic, then replicas and caching — the two biggest levers in everyone's playbook — don't help. A write-bound workload has only two levers: vertical scaling and sharding. Read-dominated load effectively adds several "virtual doublings" via replicas; write-dominated load has none.

Non-CPU invalidators that trigger sharding earlier than the formula suggests:

• Working set exceeding max RAM trajectory. If your hot dataset will outgrow the largest instance's memory (~4TB-class) within 12–18 months, cache-hit ratio collapses and CPU projections become meaningless.
• Vacuum falling behind. If autovacuum can't keep pace with update/delete churn at current scale (watch dead-tuple counts and table bloat trending up), a bigger box helps sublinearly — this is a per-node throughput problem.
• One pathological tenant. If a single customer is >30–40% of load, note that sharding doesn't fix this either — the hot tenant still lands on one shard. That triggers a different project (dedicated instance for that tenant), which is much cheaper.

The false invalidators

Two things that look like triggers but aren't: (a) 80% CPU itself — peak utilization is a symptom with no directional information until you know the trend and read/write mix; (b) fear of migration pain later — the tenant-scoping prep work everyone in this round endorsed is precisely what caps that future pain at a bounded cost.

The rollout gap, briefly

Since no one covered it: don't do an in-place resize on a hot primary. Spin up the larger instance as a replica (or use blue-green deployment if your provider supports it), let it catch up, verify replication lag < ~10 seconds sustained, fail over during your lowest-traffic window, and keep the old primary as a rollback target for 48–72 hours. Acceptance criteria: p99 latency and error rate within baseline for 24 hours post-cutover. Rollback is a failover in reverse — which is why you don't decommission the old box immediately.

Bottom line: the panel's consensus stands unless your measurements show both (a) you're within ~1.5 effective doublings of the instance ceiling and (b) demand is doubling in under ~6 months — or your workload is write-dominated with either condition approaching. Run the formula with real numbers this week; it converts your team's 50/50 opinion split into an answer.

You raise valid pressures, and Claude and GPT-5.6 are right to check the instinct to indefinitely throw hardware at unknown problems. I will concede ground on the sizing strategy, but firmly defend the timing of the resize under specific conditions.

Here is exactly when to break the rules, where I concede to the panel, and how to govern the operational risks that were left out.

When to Upgrade Immediately vs. Diagnose First

Claude argues for diagnosing before spending anything. I concede that if your 80% CPU spike appeared overnight after a new feature release, scaling up is a dangerous band-aid over a missing index or an N+1 query loop. It will just mask the bug until the new hardware inevitably maxes out a few days later.

However, immediate doubling or quadrupling of the instance is preferable to a one-week diagnosis ONLY IF these two measured conditions are met:

1. User Pain: The 80% CPU peak is already causing active incident-level behavior—such as 504 Gateway Timeout errors, API rate limiting, or p99 response times crossing your acceptable SLA threshold (e.g., >2 seconds).
2. Organic Growth: Your monitoring shows the CPU has been creeping up steadily week-over-week for months in exact correlation with user/traffic growth.

If those two conditions are true, a 10-person startup should not spend a week enduring degraded performance while an engineer fishes through pg_stat_statements. You double the instance today to stop the bleeding, restore the user experience, and buy the engineering team the calm, unpressured week they need to properly diagnose and tune the database as Claude and GPT suggest.

When to Buy the "Maximum" vs. "6–12 Month Headroom"

GPT-5.6 correctly points out that automatically jumping to the largest available instance (e.g., a massive 128-vCPU, 1TB RAM machine) is financially foolish if you only need a 16-vCPU machine to comfortably survive the next year. I concede this point: do not casually burn $10,000/month on AWS credits if a $1,000 upgrade solves the problem.

Evidence that justifies buying the absolute maximum instance now:

• Intolerable Downtime Windows: If you are not running in a Multi-AZ / High-Availability configuration, scaling the database requires physically stopping and starting the machine, causing hard downtime. If your business cannot tolerate this downtime more than once every two years, you buy the biggest instance you can afford right now to delay the next downtime event as long as possible.
• Hyper-Growth Trajectory: If your read/write IOPS or storage volume is doubling every 30 days (rather than steady month-over-month percentage growth). You do not want to be caught in a cycle of resizing every two months, as you will quickly hit the provider limitations on how often you can modify instance storage/compute.

If you don't meet those criteria, GPT-5.6 is right: double the current instance size to hit ~40% peak CPU, and keep the cash.

Managing the Operational Risks (Validation, Rollback, and Lag)

The panel entirely missed the operational danger of executing these changes. Before touching the instance, you must define the following:

1. Resizing and Rollback Risks If you are on a managed provider (RDS, Cloud SQL) with High Availability (Multi-AZ) enabled, a compute resize is relatively safe: the provider provisions the larger instance in the background, syncs it, and performs a DNS failover.

• Validation: Your validation metric is observing the primary DB connections drop to zero, reconnect, and the CPU baseline settling lower.
• Rollback: Rolling back a compute scale-up is technically possible, but your cache (RAM) will be evicted during the restart, which can cause a sudden CPU shock when you downgrade. Warning: If you increase allocated storage alongside compute, cloud providers universally do not allow you to shrink storage later.

2. Failover Tolerance Your application must be able to gracefully handle connection drops. If you resize the instance, the database will drop connections during the failover transition (usually 30–60 seconds). If your application does not have automatic reconnection logic or a retry-queue, users will experience outright errors during the upgrade.

3. The Read Replica "Gotcha" (Replication Lag) Both models and I recommended offloading to read replicas. What we omitted is that asynchronous read replicas introduce eventual consistency.

• If your app allows a user to update their profile and immediately redirects them to view it, reading from a replica might serve stale data (showing the old profile) because of a 50-100ms replication lag.
• Acceptable conditions: Only route traffic to read replicas if the specific endpoint or analytical job can tolerate data that is a few seconds out of date. Do not route strict read-after-write user flows to a replica without implementing application-level lag awareness.