We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Database Types Storage
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Types Storage
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your application started with one PostgreSQL database. Users, orders, products, inventory, analytics, payments, all in one instance. At the beginning, this was fine. Simple. One connection string, one backup, one place to look for data.
Then the company grew. The orders table has 500 million rows and is the bottleneck for writes. Analytical queries against the products table are locking rows and slowing down the storefront. The user authentication queries need sub-10ms , but they're competing for connection pool slots with slow inventory reports.
You could vertically scale, bigger machine, more RAM, faster CPU. But there's a ceiling. And you're paying for a beefy server that's overkill for the auth table but undersized for the orders table.
Database federation (also called functional partitioning or vertical partitioning) is the idea of splitting one big database into multiple smaller, specialized databases, each handling a different domain of your application. The users database handles authentication. The orders database handles commerce. The products database handles the catalog. Each scales independently.
Before federation:
Application → Single PostgreSQL
├── users table
├── orders table
├── products table
├── inventory table
├── payments table
└── analytics table
After federation:
Application → Users DB (PostgreSQL)
→ Orders DB (PostgreSQL)
→ Products DB (PostgreSQL)
→ Inventory DB (PostgreSQL)
→ Payments DB (PostgreSQL)
→ Analytics DB (ClickHouse)
Each database:
The application layer routes queries to the correct database based on the domain. A request to authenticate a user goes to the Users DB. A request to place an order goes to the Orders DB.
In a architecture, federation happens naturally, each service owns its database. In a monolithic application, federation requires the application code to manage multiple database connections and route queries correctly.