---
title: "Migrating Etsy’s database sharding to Vitess"
description: "Etsy migrated its long-running MySQL shard management to Vitess vindexes after an architecture spanning about 1,000 tables and shards, 425 TB of data, and roughly 1.7 million requests per second. The legacy ORM used a single index database to map records to shards, creating a scaling bottleneck and single point of failure. To avoid moving existing data, engineers built custom SQLite lookup and hybrid vindexes, changed new shard assignments to match Vitess’s hash algorithm, and introduced routing incrementally table by table with traffic ramps, rollback, and query compatibility testing. After five years, about 2,500 pull requests, and 6,000 queries, the migration removed the index database dependency, made scaling operations take days rather than months, simplified developer access, and kept database performance largely unchanged without a mass data migration."
---

# Migrating Etsy’s database sharding to Vitess

[Etsy](https://yomu.fyi/company/etsy) · Ella Yarmo-Gray · Mar 19, 2026

**Type:** Problem & solution

## Summary

Etsy migrated its long-running MySQL shard management to Vitess vindexes after an architecture spanning about 1,000 tables and shards, 425 TB of data, and roughly 1.7 million requests per second. The legacy ORM used a single index database to map records to shards, creating a scaling bottleneck and single point of failure. To avoid moving existing data, engineers built custom SQLite lookup and hybrid vindexes, changed new shard assignments to match Vitess’s hash algorithm, and introduced routing incrementally table by table with traffic ramps, rollback, and query compatibility testing. After five years, about 2,500 pull requests, and 6,000 queries, the migration removed the index database dependency, made scaling operations take days rather than months, simplified developer access, and kept database performance largely unchanged without a mass data migration.

## Context

Etsy’s sharded MySQL architecture had grown to about 1,000 tables and shards, 425 TB of data, and roughly 1.7 million requests per second. Horizontal scaling was manual and took months, the unsharded index database was a single point of failure, and developers had to manage shard details when accessing data.

## Approach / What changed

Etsy introduced Vitess as an abstraction layer, then created custom vindexes to preserve existing shard mappings without moving data. A SQLite lookup vindex handled legacy mappings, a hash vindex handled newly assigned IDs, and a hybrid vindex selected between them using a threshold. Vindexes were enabled incrementally by table, with traffic ramping, compatibility testing, monitoring, and rollback.

## Takeaways

- Custom SQLite and hybrid vindexes preserved Etsy’s random legacy shard mappings while allowing new IDs to use the Vitess hash algorithm.
- Etsy disabled scatter queries by default because an unintentionally broad query could be sent to all 1,000 shards; approved scatter queries nevertheless reduced one model’s query time from about 2 seconds to 20 milliseconds.
- The completed migration removed the index database as a single point of failure, reduced scaling operations from months to days, and avoided a massive data migration while keeping performance largely unchanged.

**Tags:** [Databases](https://yomu.fyi/topic/databases), [Migrations](https://yomu.fyi/topic/migration), [MySQL](https://yomu.fyi/topic/mysql), [Vitess](https://yomu.fyi/topic/vitess)

- Source: [Etsy](https://www.etsy.com/codeascraft/migrating-etsyas-database-sharding-to-vitess)
- Source URL: https://www.etsy.com/codeascraft/migrating-etsyas-database-sharding-to-vitess
- Ingested by Yomu: 2026-09-09T20:02:32.204Z

[Read original post](https://www.etsy.com/codeascraft/migrating-etsyas-database-sharding-to-vitess)