Uber’s Schemaless Journey: Building a NoSQL Database for Trillion Operations

In 2013, Uber was growing fast — faster than PostgreSQL could scale with it. What started as a ridesharing app built on a monolithic relational database soon ran into the hard limits of vertical scaling, consistency constraints, and operational overhead. The solution? Schemaless — Uber’s custom-built, distributed NoSQL storage system designed to handle trillions of write operations per day.

Why PostgreSQL Couldn’t Keep Up

Uber initially ran on PostgreSQL with sharding at the application level. This worked for a while, but scale broke everything:

• Write throughput bottlenecks: PostgreSQL wasn’t optimized for extremely high write rates.
• Schema evolution pain: Changing table structures across dozens of shards was slow and risky.
• Operational cost: Managing thousands of shards manually became a nightmare.

+------------------+     INSERT INTO rides ...
|   PostgreSQL     |  <----------------------  app
+------------------+
| shard_001        |
| shard_002        |   // 400+ shards
| ...              |
+------------------+

Enter Schemaless