---
title: "The Architecture of Schemaless, Uber Engineering's Trip Datastore Using MySQL"
description: "Schemaless is Uber's scalable, fault-tolerant datastore whose immutable cells are identified by row key, column name, and ref key, while JSON content remains schemaless and supports eventually consistent secondary indexes. Its worker nodes accept HTTP requests, route them to storage nodes, and aggregate results, while storage data is partitioned into typically 4096 shards, each replicated across one master and two minions in multiple data centers. Writes go to the master and replicate asynchronously, with idempotent retries, circuit breakers, failover, and configurable reads from masters or minions. To reduce loss during master failure, buffered writes persist each request to a primary and secondary cluster, though buffered data may not be immediately readable. Each shard maps to a MySQL database, where an auto-increment added_id primary key supports linear insertion and trigger processing, and MessagePack with ZLib compresses cell JSON blobs."
---

# The Architecture of Schemaless, Uber Engineering's Trip Datastore Using MySQL

[Uber](https://yomu.fyi/company/uber) · Jul 31, 2026

**Type:** Explainer

## Summary

Schemaless is Uber's scalable, fault-tolerant datastore whose immutable cells are identified by row key, column name, and ref key, while JSON content remains schemaless and supports eventually consistent secondary indexes. Its worker nodes accept HTTP requests, route them to storage nodes, and aggregate results, while storage data is partitioned into typically 4096 shards, each replicated across one master and two minions in multiple data centers. Writes go to the master and replicate asynchronously, with idempotent retries, circuit breakers, failover, and configurable reads from masters or minions. To reduce loss during master failure, buffered writes persist each request to a primary and secondary cluster, though buffered data may not be immediately readable. Each shard maps to a MySQL database, where an auto-increment added\_id primary key supports linear insertion and trigger processing, and MessagePack with ZLib compresses cell JSON blobs.

## Context

Schemaless is designed as a scalable, fault-tolerant datastore for services in Uber's infrastructure. Its background concerns include handling storage-node failures, asynchronous replication, potential data loss after master failure, efficient cell and secondary-index queries, and storing data without requiring schema changes.

## Approach / What changed

The architecture separates worker and storage nodes, partitions data into shards, and replicates each shard across a master and minions. MySQL provides the storage layer, indexes, and InnoDB caching. Idempotent requests, circuit breakers, asynchronous replication, and buffered writes to primary and secondary clusters address retries, failover, and durability.

## Takeaways

- Each storage cluster has one master and two minions, with minions distributed across multiple data centers; reads can use any available node, while writes must initially go to the master.
- Buffered writes send requests to a secondary cluster before the primary and require both writes to succeed, reducing the chance of data loss when asynchronous MySQL replication has not completed.
- Each Schemaless shard is a separate MySQL database with an entity table and index tables; the auto-increment added\_id primary key supports linear disk insertion and ordered trigger processing.

**Tags:** [Databases](https://yomu.fyi/topic/databases), [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [MySQL](https://yomu.fyi/topic/mysql)

- Source: [Uber](https://www.uber.com/us/en/blog/schemaless-part-two-architecture)
- Source URL: https://www.uber.com/us/en/blog/schemaless-part-two-architecture
- Ingested by Yomu: 2026-09-10T15:19:24.956Z

[Read original post](https://www.uber.com/us/en/blog/schemaless-part-two-architecture)