When performance degrades, the fastest reaction is often to add CPU or memory. Sometimes that works. But at scale, hardware stops addressing the underlying bottleneck. That's when architecture, not capacity, determines your ceiling. Here's how to decide whether to scale up or rethink the system:
- If your working set fits in memory, vertical scaling buys time: More RAM reduces page faults and disk reads, smoothing performance quickly. But once the active dataset already fits in memory, additional RAM delivers sharply diminishing returns.
- If the CPU is saturated by repetitive reads, hardware won't save you: High-frequency identical queries still consume CPU on execution, even if parsing and planning are cached. Adding cores increases throughput, but it doesn't eliminate redundant work.
- If contention is rising, scaling up can amplify the problem: Increasing concurrency against the same hot rows raises lock contention, coordination overhead, and context switching. In these cases, architectural changes reduce shared-state pressure more effectively than bigger machines.
- If replicas are multiplying, you're scaling symptoms: When read replicas are added to relieve CPU pressure on the primary, you're distributing load, not reducing work. That's often a signal the workload itself needs rethinking.
- If performance improves linearly with hardware, keep upgrading: The simplest test is whether doubling resources roughly doubles throughput. If it doesn't, you're likely hitting architectural limits rather than raw capacity constraints.
Vertical scaling is often the starting point. It's fast, low-friction, and sometimes enough. But durable scalability rarely comes from bigger machines alone. It comes from removing unnecessary work from the system. For a deeper technical walkthrough, check out "Stop Throwing Hardware at the Problem."
Supporting ChatGPT on PostgreSQL in Azure
Microsoft outlines how Azure Database for PostgreSQL was stretched to support ChatGPT's explosive growth, requiring careful replica tuning and architectural evolution. It's an impressive case study in how far Postgres can go with deep engineering investment. Most teams do not have the resources to redesign their stack at that scale, which is why where you place caching and query isolation becomes the real architectural decision. We unpack that tradeoff in more detail in The Hidden Complexity of Postgres Scaling.
State of Databases 2026
This 2026 snapshot shows PostgreSQL solidifying its dominance in usage and adoption while major acquisitions and funding signal market consolidation and platform bundling. Standalone vector systems are losing ground as core engines like Postgres, Oracle, and SQL Server absorb vector search and AI capabilities natively. At the same time, security incidents and rapid innovation highlight that as ecosystems grow more powerful, they also become more complex to operate and secure.
New on our blog: MySQL 9.6: Foreign Key Cascades Finally Hit the Binary Log
MySQL 9.6 now logs foreign key cascade operations in the binary log, fixing long-standing replication edge cases. For teams relying on replication-based tooling, this is a meaningful operational improvement.