{"id":26109,"date":"2025-03-27T12:02:59","date_gmt":"2025-03-27T19:02:59","guid":{"rendered":"https:\/\/www.pingcap.com\/?p=26109"},"modified":"2025-03-27T12:03:01","modified_gmt":"2025-03-27T19:03:01","slug":"scaling-up-how-easypost-future-proofed-data-infrastructure-distributed-sql","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/scaling-up-how-easypost-future-proofed-data-infrastructure-distributed-sql\/","title":{"rendered":"Scaling Beyond Limits: How EasyPost Future-Proofed Its Infrastructure with Distributed SQL"},"content":{"rendered":"

When legacy infrastructure hits its limits, innovation isn\u2019t just a choice \u2014 it\u2019s a necessity. For EasyPost<\/a>, a leader in logistics technology, scaling up meant more than just more hardware. It meant a fundamental shift in their approach to data. <\/p>\n\n\n\n

In this customer story, we explore how EasyPost\u2019s infrastructure team, led by Head of Infrastructure Adam Firester, navigated a complex scaling challenge and found their answer in \ud2f0DB<\/a>, a powerful distributed SQL database<\/a>.<\/p>\n\n\n\n

<\/span>The Scaling Up Challenge: A 32-Terabyte Problem<\/span><\/h2>\n\n\n\n

EasyPost, the all-in-one shipping API platform that connects e-commerce companies with major carriers like USPS, UPS, and FedEx, has grown substantially since its founding in 2012. At the center of this growth was a legacy MySQL 5.7 monolith \u2014 now a 32-terabyte (TB) beast with serious limitations.<\/p>\n\n\n\n

\u201cWe\u2019d been talking about sharding for over a decade,\u201d said Firester. \u201cBut nothing ever tackled the core issue: Shard zero just kept growing. We were hitting the max local storage on our IBM bare metal servers. Backups would run over each other. DDL changes took hours. We were reaching the end of our runway.\u201d<\/p>\n\n\n\n

The company needed more than incremental fixes. They needed a transformation.<\/p>\n\n\n\n

<\/span>Evaluating the Options<\/span><\/h2>\n\n\n\n

EasyPost\u2019s team considered the classic trio of solutions for scaling up its data infrastructure:<\/p>\n\n\n\n

    \n
  1. Sharding<\/strong>: Complex and ineffective against their primary bottleneck. Sharding<\/a> is a database architecture pattern that involves splitting a database into multiple smaller databases, or shards. While sharding can be an effective way to scale a database, it is also a complex solution that can introduce a number of challenges. In EasyPost’s case, sharding was ineffective because it did not address the core issue of shard zero’s continuous growth.
    <\/li>\n\n\n\n
  2. Outsourcing the problem<\/strong>: Ideal in theory, but not aligned with their current ops. Outsourcing the problem to a cloud provider could have been a potential solution, but it was not aligned with EasyPost’s current operations.
    <\/li>\n\n\n\n
  3. Replatforming to a new database<\/strong>: Risky, but potentially the most impactful. Replatforming to a new database would be a risky move with the possibility of substantial code refactoring, but it was also the solution with the most potential impact.<\/li>\n<\/ol>\n\n\n\n

    After an extensive review of options across these categories, one solution stood out: TiDB.<\/p>\n\n\n\n

    \u201cWe chose TiDB because it aligned with both our current constraints and future ambitions,\u201d Firester explained. \u201cWe could run it on bare metal now, but it\u2019s cloud-ready. That gave us optionality.\u201d<\/p>\n\n\n\n

    <\/span>Scaling Up: Why TiDB?<\/span><\/h2>\n\n\n\n

    Several features made TiDB the clear front-runner:<\/p>\n\n\n\n