Why it matters
Phoenix drastically lowers the barrier to HBase adoption. Applications that would otherwise need custom HBase client code can use JDBC. BI tools can query HBase directly through the Phoenix driver. Analysts can write SQL instead of scan-and-filter loops. This ecosystem access is Phoenix's biggest value proposition.
Phoenix also formalizes patterns that HBase users would otherwise build ad hoc: secondary indexes, transactions, joins, upserts. These are all in the Phoenix SDK rather than reinvented per project.
The architecture
Phoenix has a client-side query engine (JDBC driver) and server-side execution via coprocessors installed on every RegionServer. The client parses SQL, plans a query, and dispatches parts of the plan to the appropriate RegionServers as coprocessor calls. Aggregation, filtering, and even join processing can happen server-side.
Tables and views are Phoenix concepts layered over HBase tables. Phoenix schemas define primary keys (which map to HBase row keys), typed columns (which map to HBase columns), and secondary indexes (which map to separate HBase index tables).
How it works end to end
A SELECT that filters by primary key becomes a Phoenix range scan directly on the target region. A SELECT with aggregation (COUNT, SUM, AVG) pushes the aggregation into a coprocessor endpoint that returns pre-aggregated results, dramatically reducing network transfer.
Secondary indexes are automatic. CREATE INDEX creates an index table, and INSERT, UPDATE, and DELETE statements automatically maintain the index. The query planner uses indexes when it thinks they will be cheaper than a full scan.
Transactions (via Apache Omid or Tephra integration) provide ACID semantics on top of HBase's write path. This enables multi-row updates that either fully commit or fully roll back. It is the biggest departure from vanilla HBase semantics.