TubeSum ← Transcribe a video

Scaling Writes 1: Vertical Scaling & Database Choice

0h 01m video Published Jul 7, 2026 Transcribed Aug 4, 2026 Hello Interview Hello Interview
Intermediate 2 min read For: Software engineers and system designers preparing for technical interviews or making database scaling decisions.
AI Trust Score 70/100
⚠️ Average / Some Fluff

"Delivers on the promise of explaining vertical scaling and database choice, though it's a brief overview rather than a deep dive."

AI 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.

[00:02]
The 10,000 users question

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.

[00:16]
Vertical scaling is viable

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.

[00:28]
OpenAI's example

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.

[00:42]
Do the math first

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.

[00:55]
Consider the right database

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.

[01:09]
Series overview

This is part 1 of 4 on scaling writes. The full breakdown is available on hellointerview.com.

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.

Mentioned in this Video

Study Flashcards (4)

What is the approximate cost of renting a machine with hundreds of cores per month?

easy Click to reveal answer

A few thousand dollars.

00:16

How did OpenAI scale ChatGPT's write operations?

medium Click to reveal answer

They used a single primary database for writes, with hundreds of read replicas for queries.

00:28

If 10,000 users write every 10 seconds, what is the write throughput in TPS?

easy Click to reveal answer

1,000 TPS.

00:42

What is the main difference between Postgres and Cassandra regarding write performance?

medium Click to reveal answer

Postgres updates a B-tree on every insert, while Cassandra uses an LSM tree that appends to a log, making writes faster.

00:55

💡 Key Takeaways

💡

Vertical scaling is viable

Challenges the assumption that massive scale requires distributed databases, offering a simpler and cost-effective alternative.

00:16
📊

OpenAI's single primary

Provides a real-world example that a single write node can handle immense scale, validating the vertical scaling approach.

00:28
🔧

Do the math first

Emphasizes the importance of calculating actual throughput before designing for scale, avoiding unnecessary complexity.

00:42
💡

Database choice matters

Highlights that the choice of database technology can have a significant impact on write performance, not just scaling.

00:55

[00:02] "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

[00:16] 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

[00:28] 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

[00:42] 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

[00:55] 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

[01:09] 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.

More from Hello Interview

View all

⚡ Saved you 0h 01m reading this? Transcribe any YouTube video for free — no signup needed.