Cloud Parts

Apache HBase

The Hadoop world’s Bigtable: huge sorted tables split into regions, each served by one RegionServer, with files kept in HDFS.

What it is
Wide-column stores
Type
Open source
Made by
Apache Software Foundation
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

An HBase table is a set of rows sorted by row key (raw bytes), with columns grouped into column families. The table is cut into regions, each a contiguous range of row keys served by exactly one RegionServer. Regions split as they grow, and the HMaster assigns and rebalances them; ZooKeeper tracks which master is active. A client looks up the region in the hbase:meta catalog table, then talks to that RegionServer directly. Each write is appended to the server’s write-ahead log (WAL) in HDFS, then held in the MemStore for its column family, which is later flushed to an HFile (a format based on Bigtable’s SSTable) and compacted. Because one server owns each row, reads and writes are strongly consistent and every mutation is atomic within a row, but not across rows.

That design has a cost: when a RegionServer dies, its regions can’t be read until they are reassigned and recovered, and detecting the failure alone takes 20 to 30 seconds. Rows are sorted, so sequential keys such as timestamps send every write to one region; row keys are usually salted, hashed or reversed to spread the load. You access HBase through its Java API, REST or Thrift, and Apache Phoenix adds SQL and JDBC on top. HBase is free under Apache 2.0. HBase 3.0.0 (August 2026) requires JDK 17 and drops Hadoop 2; the 2.6 and 2.5 lines still get releases. Amazon EMR runs it, optionally with its files in S3; Azure HDInsight 5.1 ships the older HBase 2.4; Google Cloud Bigtable accepts a customised HBase client.

Why teams pick it

  • Strongly consistent reads and writes, atomic per row, with check-and-put for compare-and-swap
  • Scales to billions of rows by splitting regions automatically and adding RegionServers
  • Rows sorted by key make scans over adjacent rows cheap
  • Fits the Hadoop stack: files in HDFS, and Spark, Hive, Impala and Flink can read and write tables
  • Code written against the HBase API can move to Google Cloud Bigtable

Watch out for

  • A heavy stack to run: HDFS, ZooKeeper, HMaster and RegionServers; its own guide suggests it only for hundreds of millions of rows or more, on at least five DataNodes
  • When a RegionServer fails, its regions are unavailable until reassigned, and detection alone takes 20 to 30 seconds
  • No secondary indexes, typed columns or multi-row transactions, and a poorly chosen row key sends all traffic to one region
  • Its ecosystem is shrinking: Facebook moved Messenger off HBase in 2018, HDInsight still ships HBase 2.4, and Phoenix doesn’t yet support HBase 3.0
  • HBase 3.0 needs JDK 17, drops Hadoop 2 and puts the master in the client’s path for finding regions

Alternatives

What all wide-column stores have in common →
Apache CassandraOpen sourceA masterless, wide-column database that spreads and replicates partitions around a ring of equal nodes, with consistency chosen per request.ScyllaDBCommercialA C++ rewrite of Cassandra’s design with one shard per CPU core, speaking both CQL and the DynamoDB API.

How it fits with other technologies

A pre-split table with salted, reverse-timestamp row keys, in the HBase shell · bash

hbase shell <<'EOF'
# four regions from the start; keys begin with one hex salt character
create 'metrics', {NAME => 'd', VERSIONS => 1}, {SPLITS => ['4', '8', 'c']}

# key = salt (first hex digit of md5(host)) # host # (Long.MAX_VALUE - epoch ms),
# so writes spread across regions and each host's newest rows sort first
put 'metrics', 'a#web-01#9223370245568575807', 'd:cpu', '0.72'
put 'metrics', 'a#web-01#9223370245568575807', 'd:mem', '0.41'

get 'metrics', 'a#web-01#9223370245568575807'
scan 'metrics', {ROWPREFIXFILTER => 'a#web-01#', LIMIT => 10}
EOF

HBase or Cassandra?#

Both store wide rows in sorted files, but they split and replicate data in opposite ways. From each project’s docs:

Apache HBaseApache Cassandra
LineageBigtable: one server owns each range of rowsDynamo plus Bigtable: equal nodes, each partition on several replicas
ConsistencyStrong, with atomic mutations within a rowChosen per request; conflicting writes resolve by timestamp
When a server failsIts regions are unreadable until reassigned (detection takes 20 to 30 seconds)Other replicas keep serving if the consistency level can still be met
OrderingRows sorted by key across the whole tablePartitions placed by hash; rows sorted only within a partition
StorageHFiles and WAL in HDFS, or S3 on Amazon EMRSSTables and commit log on each node’s own disks
Processes to runHDFS, ZooKeeper, HMaster, RegionServersOne kind of node
  • Facebook tested both in 2010 and chose HBase for Messages because of its simpler consistency model and its HDFS foundation; in 2018 it moved Messenger to MyRocks.

Where HBase runs today#

Self-managed

Apache 2.0

3.0.0 for new clusters on JDK 17 and Hadoop 3, or the maintained 2.6 and 2.5 lines. You also run HDFS and ZooKeeper.

Amazon EMR

HBase 2.6.4

EMR 7.14.0 includes HBase 2.6.4. Since EMR 5.2.0 the HBase root directory, store files and metadata can live in S3, so clusters are sized for compute; only one cluster at a time writes to that location, plus optional read replicas.

Azure HDInsight

HBase 2.4.11

HDInsight 5.1 ships HBase 2.4.11 and Phoenix 5.1.2, a line the HBase project no longer lists for download. HDInsight 4.0 and 5.0 were retired on March 31, 2025; no retirement date is announced for 5.1.

Google Cloud Bigtable

HBase-compatible client

Not HBase, but Google offers a customised HBase client for Java. Coprocessors, namespaces, snapshots and region management aren’t supported, since Bigtable manages its tablets itself.

See it in a real stack

No architecture uses Apache HBase yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2006–2026

Google’s 2006 Bigtable paper described a store of sorted rows on top of its file system. Hadoop had copied that file system as HDFS, but had no way to read and update single records in huge tables. In February 2007 Mike Cafarella posted code for “HBase, a BigTable-like file store” to Hadoop’s issue tracker. Jim Kellerman and Michael Stack, at the search start-up Powerset, took it forward as a Hadoop contrib module whose goal was a system “as similar to Google’s Bigtable as possible”. The first working version shipped with Hadoop 0.15.0 in October 2007.

HBase became a top-level Apache project in April 2010. That November Facebook chose it over MySQL and Cassandra for its new Messages system. HBase 1.0 followed in February 2015, when the ASF named Apple, Facebook, Pinterest, Salesforce, Xiaomi and Yahoo among its users.

Use has thinned since. In 2018 Facebook moved Messenger from HBase to MyRocks, to serve data from flash and fit its MySQL replication topology. Development continued: 2.0 came in 2018, and 3.0, eight years later, in August 2026.

Why it’s built this way

Copy Bigtable rather than invent a new design
The project’s stated goal was to stay as close to Bigtable as possible and avoid reinventing the wheel, so HFiles follow Bigtable’s SSTables and regions follow its tablets.
Keep the files in HDFS
HDFS already gave replication, end-to-end checksums and rebalancing, so HBase didn’t need its own replication inside a cluster, and Hadoop teams already knew how to run it.
One server per region
Routing all reads and writes for a row through one RegionServer orders every write and lets reads see the latest data. The price is a gap in availability while a failed server’s regions are recovered.

Timeline

  1. 2006

    Google publishes the Bigtable paper

  2. 2007

    Mike Cafarella posts HBase code; it ships in Hadoop 0.15.0

  3. 2010

    Top-level Apache project in April; Facebook picks it for Messages

  4. 2015

    HBase 1.0 is released in February

  5. 2018

    HBase 2.0; Facebook moves Messenger from HBase to MyRocks

  6. 2026

    HBase 3.0.0 requires JDK 17 and drops Hadoop 2

Sources18 · facts checked 6 October 2026

Improve this page on GitHub