Case Study 1.1: UberEats and SQL for fast product launches

Why does UberEats use SQL for faster product launches?

Goal: Learn why modern data apps use SQL

Food delivery apps like UberEats and DoorDash are betting on the rapidly expanding and highly competitive food delivery industry. To gain market-share, UberEats experiments with different app features to quickly find what improves buyer and driver engagement, and drive new revenue streams. UberEats’ app teams use SQL, a popular programming language for data, to achieve product build goals, as follows.

App features: For example, if UberEats wants to launch a new feature such as "frequent orders" for a buyer, the app teams can use SQL to quickly retrieve the data on the buyer’s previous orders and show them as a suggestion for their next order. Alternately, when launching a new feature such as "group ordering" for party orders, UberEats can use SQL to quickly retrieve the data on the buyers who have ordered together in the past and show them as a suggestion to other buyers.

Real-time updates: The app team uses SQL to update the location and status of food deliveries. The app displays this information to the buyer in real-time, allowing them to track the progress of their food delivery. Restaurants can update their food capacity (e.g., no more salads for the meal) through a restaurant portal (also powered by SQL). Furthermore, SQL is used to monitor and act on a delivery partner's performance.

Data analysis and optimization: UberEats uses SQL to analyze data on how users interact with the app, such as which features are most popular or which areas have the highest demand for food delivery. This information is used to optimize and improve the user experience. For example, SQL can be used to identify the most popular dishes in certain areas, and increase the inventory of those dishes in those areas.

But wait a minute…I read a blog saying SQL was slow.

And only ancient companies use it. Did I read that wrong?

Welcome to your first lesson! Over the past 20 years, sub-fields in Computer Science (CS) have experienced significant cycles of growth and decline, similar to a pendulum swinging back and forth. These cycles have included AI winters, noSQL movements, chip design winters, among others. Often the predominant use cases change, and the sub-fields are reinvented around a few core principles.

In the 2020s, SQL is experiencing a big upswing for “modern” data stacks, and we expect this trend to continue for several years. To gain a better understanding of past and future cycles, it’s crucial to understand why these changes occur, and the fundamental principles that underpin each field. In the rest of this chapter, we highlight the core of these changes.

In the early 2000s, SQL databases, which were the most popular databases at the time, were designed to work on a small number of high-end, expensive and ultra-reliable servers to process data tables in banks, retail and e-commerce. However, they became ineffective and costly to manage the rapidly growing web-scale data, such as web pages, user activity, and media. At the same time, big players like Google and Amazon changed the game by building (cloud) data centers with millions of cheap, commodity servers. App engineers started to build appropriate data stacks and new hybrids for the specific use cases they were tackling.

Specifically, Google picked a hybrid approach based on the use case.

1. Google's web search and Gmail stacks, for example, could not be built with SQL or traditional databases in the market, because they were not equipped to handle these new use cases and scale in a cost-efficient way. As a result, Google engineers adopted, adapted, and invented a variety of techniques to build large-scale distributed systems to support these new use cases. These included Google File System (GFS), MapReduce for processing data, and BigTable for key-value stores. In parallel, industry dubbed this as the start of the noSQL movement, and built Hadoop and various commercial products.

2. Google's critical Ads data system, which powered Google’s billions in revenue, was built around MySQL and custom servers interfacing with MySQL. These apps needed the reliability and flexibility of SQL systems to help app teams to rapidly iterate on customer needs.

How to think of SQL and NoSQL in 2026

These guidelines are based on the 2026 perspective, where the line between SQL and NoSQL has blurred significantly.

Note: This was not the case in the 2000s, when SQL was the incumbent, and NoSQL was a niche but fast-growing market. This was also not the case in the early 2020s, when JSONB was not a first-class citizen in SQL databases.

The "Swiss Army Knife" (Modern SQL) vs. Ultra-Specialized Systems

For about 80% of all apps (apps like Instagram, banking apps, or school portals), a modern SQL database like PostgreSQL or MySQL is the "Go-To" choice.

In the past, SQL could only handle rigid tables. Today, it has "swallowed" its competitors' best features, becoming a true "Swiss Army Knife" for data. This is a "Game Changer" for 2020s:

The Modern SQL Table: One Table, Three Worlds

1. Standard Columns (The 80%): The User ID and Name are classic SQL. They are rigid, organized, and ensure your data stays clean.

2. JSONB Column (The "NoSQL" part): Notice the Preferences. In the old days, if Bob wanted to add a "Favorite Color" but Alice didn't, you’d have to change the whole table structure. Now, you just toss it into the JSON "bucket." It’s flexible and fast. This is why people say SQL swallowed the NoSQL movement.

3. Vector Column (The "AI" part): The Taste Profile represents what kind of music a user likes via AI embeddings.

SQL vs. Pandas (The RAM Wall)

Students often ask: "Why use SQL for UberEats data when I have Pandas in Python?"

• Pandas (How): You tell Python how to do the math. It’s great for data science, but it has to fit the data into your computer's RAM. If UberEats has 100GB of active orders and you have 16GB of RAM, Pandas crashes.

• SQL (What): You tell the database what you want. The engine handles the scale, even if the data is spread across 1,000 servers.

The Why: Telling a machine what to do (Declarative) is the ultimate "Lazy Win." It lets the database optimize your query while you focus on features.

When to go Ultra-Specialized? [The 2026 View]

If Modern SQL is so good, why do the other systems even exist? This is for the remaining 20% when you need something more specialized.

• Ultra-Specialized Key-Value Stores: For when you need sub-millisecond speed for text-based lookups (like Spotify’s lyrics).

• Ultra-Specialized Graph Databases: For when the relationships between data (like a social network's "friend of a friend") are more important than the data itself.

The goal for most developers in 2025 is to start with the 80% (SQL) and only move to specialized systems when the scale demands it.

The NoSQL To SQL Migration

HBase Deprecation at Pinterest
Why Pinterest moved away from NoSQL back to SQL systems. A case study in choosing the right tool for the job.

Why NoSQL Deployments Are Failing at Scale
Industry analysis on NoSQL limitations and why companies are returning to SQL-based systems.

Why Companies Transitioned Data Stacks From NoSQL to SQL

Here is an excellent summary of why and how Google’s Spanner evolved from a pure key-value store to a SQL system. Keep your focus on the big picture and get a flavor for tradeoffs. (It’s a PhD level paper, so I don’t expect you to understand all the details.)

Optional Reading: Quickly Scan Real-World Data Architecture Decisions

Learn from engineering teams at scale - how they chose and evolved their data systems:

From SQL to Distributed Systems

How Uber Serves Over 40 Million Reads Per Second
Uber's journey from MySQL → BigQuery, Spanner, and PrestoSQL. See how they handle massive scale with integrated caching.

Spotify's Data Platform Explained
Deep dive into Spotify's MySQL and BigQuery infrastructure. Learn how they process billions of events daily.

Building and Scaling Notion's Data Lake
How Notion scaled PostgreSQL to handle their collaborative workspace data. Real-world PostgreSQL optimization at scale.