At its peak, Pinterest ran roughly 50 HBase clusters on 9,000 EC2 instances holding over 6 petabytes of data. By the end of 2021, the company decided to deprecate it entirely, splitting its workloads across four successor systems.

Introduced in 2013, HBase was Pinterest’s first NoSQL datastore, and it quickly became one of the most widely used storage backends in the company. It powered the graph service (Zen), a wide-column store (UMS), monitoring storage (OpenTSDB), metrics reporting (Pinalytics), a transactional layer (Sparrow, built on Apache Phoenix Omid), and a secondary-indexing service (Ixia) — the foundation under smartfeed, the URL crawler, user messages, pinner notifications, ads indexing, shopping catalogs, and more. At its peak, Pinterest ran around 50 clusters on 9,000 AWS EC2 instances holding over 6 petabytes of data, with primary and standby clusters kept in sync via write-ahead-log replication for failover.

Read the five complaints backwards and the requirements for a successor come into focus. It had to be cheaper to maintain — no five-year gap to upstream, no two-year odyssey just to upgrade a version. It had to natively support what HBase’s simple NoSQL interface couldn’t: stronger consistency and distributed transactions, so a service like Zen wouldn’t need its own bolted-on transaction layer to avoid leaving a graph half-updated. It had to fit Pinterest’s scale on fewer than six data replicas. And, given the industry’s drift away from HBase, it had to have a community and talent pool that would still exist in three to five years.

Pinterest wasn’t the only team inside the company that had noticed HBase’s limits. Other groups had already found it underperformed dedicated systems for their workloads — worse than newer solutions for OLAP-style analytics, and not as performant or infra-efficient as KVStore, an in-house key-value store built on RocksDB, for simple lookups. Several initiatives were already underway to move specific workload types off HBase before the full deprecation decision was made: online analytics to Druid/StarRocks, time series data to an in-house store called Goku, and key-value use cases to KVStore.

That left one category unaccounted for: the use cases that genuinely needed NoSQL-style horizontal scale and also needed the query power and ACID guarantees of a traditional relational database. Nothing already in flight covered that combination.

For that remaining slice of use cases, Pinterest needed “a new technology that offers great scalability like a NoSQL database while supporting powerful query capabilities and ACID semantics like a traditional RDBMS.” They chose TiDB, a distributed NewSQL database, as the technology that satisfied most of those requirements. Combined with the analytics, time-series, and key-value workloads already being routed elsewhere, this gave Pinterest, for the first time, a viable path to a complete HBase deprecation — something that had once been considered close to impossible given how deeply the system was embedded across the company.

Pinterest is explicit that this call came only “after a thorough evaluation with extensive feedback gathering from relevant stakeholders” — not a snap judgment about a system that had, after all, been durable, scalable, and generally performant for most of a decade. This particular post is the first of a three-part series: the next covers how they evaluated TiDB against alternatives with production shadow traffic, and the third covers the unified storage service that replaced the individual Zen/UMS/Ixia layers built on top of HBase.

A full system retirement gets easier the moment you stop insisting on one replacement — let each workload’s real complaint pick its own successor.