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

  1. Use a Badger version that supports the compression type the tables were written with (upgrade)
  2. Rebuild the data directory by exporting with the old/new writer and importing with your binary: db.Backup + db.Load
  3. Do not copy SST files across Badger major versions; always migrate via export/import
  4. 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

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


AI-assisted analysis of dgraph-io/badger@2a001d466f (2026-09-05). Data as JSON: /api/errors/8b9000ce005dd440. Report an issue: GitHub.