dgraph-io/badger · critical
Unsupported compression type
Error message
Unsupported compression type
What it means
Block decompression switches on the table's configured compression algorithm; the default case means the algorithm value stored in the table options is not one of the supported types (zstd or snappy), so Badger cannot decompress the block.
Source
Thrown at table/table.go:851
if err != nil {
z.Free(dst)
return y.Wrap(err, "failed to decompress")
}
case options.ZSTD:
sz := int(float64(t.opt.BlockSize) * 1.2)
// Get frame content size from header.
var hdr zstd.Header
if err := hdr.Decode(b.data); err == nil && hdr.HasFCS && hdr.FrameContentSize < uint64(t.opt.BlockSize*2) {
sz = int(hdr.FrameContentSize)
}
dst = z.Calloc(sz, "Table.Decompress")
b.data, err = y.ZSTDDecompress(dst, b.data)
if err != nil {
z.Free(dst)
return y.Wrap(err, "failed to decompress")
}
default:
return errors.New("Unsupported compression type")
}
if b.freeMe {
z.Free(src)
b.freeMe = false
}
if len(b.data) > 0 && len(dst) > 0 && &dst[0] != &b.data[0] {
z.Free(dst)
} else {
b.freeMe = true
}
return nil
}
View on GitHub (pinned to 2a001d466f)
Solutions
- Use a Badger version that supports the compression type the tables were written with (upgrade)
- Rebuild the data directory by exporting with the old/new writer and importing with your binary: db.Backup + db.Load
- Do not copy SST files across Badger major versions; always migrate via export/import
- If only one table is affected, quarantine it and restore from backup
Example fix
// before: copying v4 sst files into a v2 badger data dir // after: migrate data through the API oldDB.Backup(w, 0) newDB.Load(r, maxPendingWrites) // newDB built with a version supporting the compression
Defensive patterns
Strategy: fallback
Try / catch
db, err := badger.Open(opt)
if err != nil && strings.Contains(err.Error(), "Unsupported compression type") {
// upgrade badger to a version supporting the table's compression
// or migrate data via Backup/Load from a compatible binary
} Prevention
- Never downgrade Badger on an existing data directory without migrating
- Migrate across versions using db.Backup + db.Load, never raw file copies
- Pin Badger versions consistently across all services sharing a data dir
When it happens
Trigger: Reading a block whose table was created with a compression enum value unknown to this Badger build — files written by a newer Badger version with a compression type this binary doesn't support, or a corrupted option byte.
Common situations: Downgrading Badger after tables were written with a newer compression option; copying SSTs from a v3/newer deployment into an older version's directory; binary-level corruption of table metadata.
Related errors
- initIndex crashed: %v %s
- invalid table size in footer. Data corrupted
- invalid checksum length in footer. Data corrupted
- invalid index length in footer. Data corrupted
- invalid checksum length. Either the data is corrupted or the
AI-assisted analysis of dgraph-io/badger@2a001d466f (2026-09-05).
Data as JSON: /api/errors/8b9000ce005dd440.
Report an issue: GitHub.