The short answer
Phoenix 4.x is the release line built for HBase 1.x. HBase 2.x clusters are supported by the Phoenix 5.x line. When a Phoenix 4.x client and its server-side coprocessors run against HBase 2.x, DDL such as CREATE TABLE ... COMPRESSION='SNAPPY' can fail before compression semantics are even evaluated — the coprocessor or system-table layer breaks first. So the fix is not a different compression property; it is moving to the Phoenix release that matches HBase 2.x, then re-applying compression at the HBase column-family level.
Likely explanation vs. confirmed facts
Likely explanation: the failure appeared only after the cluster move, which points to a Phoenix/HBase version mismatch rather than a syntax problem. Phoenix does not implement its own compression — it translates COMPRESSION into the HBase column-family attribute. If the Phoenix layer can't load correctly on HBase 2.x, the DDL never reaches that translation cleanly.
Confirmed mechanics (well-established behavior):
- Compression lives on the HBase column family, not in Phoenix metadata. You can always inspect and change it with the HBase shell.
- Changing
COMPRESSION affects new writes. Existing store files keep their old encoding until a major compaction rewrites them. - A codec can parse fine but fail at runtime if native libraries or codec classes are missing on the RegionServers (a classic issue with LZO/LZ4/ZSTD; SNAPPY and GZIP availability is still deployment-dependent).
What to do, in order
- Confirm the version pairing. Check the exact Phoenix and HBase versions against the compatibility matrix for your distribution. If you are on Phoenix 4.x with HBase 2.x, plan an upgrade to the matching Phoenix 5.x release — including server-side coprocessors and system tables — in a test cluster first. Do not attempt an in-place HBase 2 upgrade while leaving Phoenix 4.x jars behind.
- Check codec availability. Ensure the compression codec's native libraries are installed on every RegionServer, not just the client node.
- Apply compression at the HBase level if needed. After Phoenix creates the table, you can set or change compression directly:
# HBase shell
disable 'MY_SCHEMA.MY_TABLE'
alter 'MY_SCHEMA.MY_TABLE', {NAME => '0', COMPRESSION => 'SNAPPY'}
enable 'MY_SCHEMA.MY_TABLE'
describe 'MY_SCHEMA.MY_TABLE' # confirm the CF shows the codec
- Rewrite existing data. Run a major compaction so old store files are re-encoded:
major_compact 'MY_SCHEMA.MY_TABLE'
Then check RegionServer logs and store-file listings to confirm new HFiles actually use the codec. Without this step, describe showing the new value proves nothing about on-disk data.
On the open questions
Whether a given Phoenix 5.x release re-enables or changes specific compression handling for HBase 2.x is version- and vendor-specific — verify against the release notes of the exact build you deploy rather than assuming parity with 4.x behavior. Setting compression via the HBase shell after Phoenix table creation is a common workaround and is generally safe because Phoenix reads whatever the column family provides, but confirm read/write behavior in a test cluster before relying on it in production.
One missing detail would sharpen this: the exact exception and stack trace, and whether the failure occurs at CREATE/ALTER time or later during compaction or reads. A DDL-time coprocessor error confirms the version-mismatch path; a compaction-time codec error points to missing native libraries instead.
phoenix