---
title: 'Scaling Writes 1: Vertical Scaling & Database Choice'
source: 'https://youtube.com/watch?v=Jla1aOtI9ao'
video_id: 'Jla1aOtI9ao'
date: 2026-08-04
duration_sec: 87
---

# Scaling Writes 1: Vertical Scaling & Database Choice

> Source: [Scaling Writes 1: Vertical Scaling & Database Choice](https://youtube.com/watch?v=Jla1aOtI9ao)

## Summary

This video is the first in a four-part series on scaling database writes. It addresses a common interview question about handling write throughput at scale, arguing that vertical scaling on a single powerful database instance is often sufficient and that choosing the right database technology is more important than prematurely adding complexity.

### Key Points

- **The 10,000 users question** [00:02] — The interviewer's question about handling 10,000 users may indicate they are stuck in 2010 thinking or want to test your knowledge of vertical scaling. It's a prompt to discuss scaling strategies.
- **Vertical scaling is viable** [00:16] — You can rent machines with hundreds of cores for a few thousand dollars a month, so you don't need a massive database cluster to handle large scale. This is a cost-effective and simpler approach.
- **OpenAI's example** [00:28] — OpenAI scaled ChatGPT with a single primary database for writes, albeit with hundreds of read replicas for queries. This demonstrates that a single write node can handle significant load.
- **Do the math first** [00:42] — Calculate your actual write throughput. For example, 10,000 users writing every 10 seconds equals 1,000 transactions per second (TPS), which is trivial for a single database instance.
- **Consider the right database** [00:55] — If you outgrow a single Postgres instance, question whether it's the right database. Postgres uses a B-tree index that updates on every insert, while databases like Cassandra use an LSM tree that appends to a log, making writes faster.
- **Series overview** [01:09] — This is part 1 of 4 on scaling writes. The full breakdown is available on hellointerview.com.

### Conclusion

The key takeaway is to avoid premature complexity: vertical scaling and choosing the right database can handle most write loads, and you should calculate your actual throughput before designing a distributed system.

## Transcript

"We might have 10,000 users. How will we handle rights?" There's only two possibilities. Either A, they're hopelessly stuck in 2010 where that number was large, or B, they want to make sure you know about vertical
scaling. You don't need a massive database cluster to handle immense scale. You can rent boxes with hundreds of cores for a few grand a month. Maybe you don't believe this operates at scale. OpenAI scaled out their service
of ChatGPT with only a single primary serving rights. Now, that's admittedly with hundreds of read replicas for queries, but you get the point. So, do the math first. What's your actual write throughput, and does it fit on one big
beefy box? If we assume 10,000 users are making rights every 10 seconds, that's 1,000 TPS. Nothing. That reflection helps your interviewer know you don't sprinkle complexity on a system that
doesn't need it. If you really have outgrown a single Postgres instance, ask if it's even the right database. Postgres updates a B-tree on every insert, whereas other databases like Cassandra use an LSM tree, which
basically just append to a log. This is way faster for rights. scaling rights in this series, so follow for more and view the whole scaling rights pattern breakdown on our website hellointerview.com.