Loki 4.0 hits RC: the Go module path moves to /v4, the V2 query engine is unplugged, BoltDB shipper retires

Loki 4.0 started producing release candidates on November 5, three of them in two days. Reading the breaking-change list produced one thought: this release is settling old debts in one go.

The easiest one to miss, and the one that bites

The module path is now github.com/grafana/loki/v4.

That looks like an import detail, and it means: any downstream project that imports Loki packages directly (custom clients, operator wrappers, internal forks) must change its import path, or it will resolve two copies of the module with two sets of types and unusually confusing errors.

If you only deploy binaries, this does not concern you. If you maintain anything importing Loki internals, go look now.

What got removed

These are not tweaks. They are deletions:

Removed	Notes
V2 query engine	Unplugged from config and modules
BoltDB shipper backends	Old index and chunk backends retire with it
/api/prom endpoints	The old API surface closes
SSD (Simple Scalable Deployment) targets	Deployment shapes converge
Experimental variants() queries	Experimental LogQL syntax removed
row_shards, disable_broad_index_queries and friends	Historical schema leftovers

The signal behind all of it: the cost of staying compatible finally became unaffordable. Every compatibility layer a log system carries makes the query path longer and optimisation harder. 4.0 cuts the old roads to get a clean execution path.

The one that will hit your bill

S3 storage classes are limited to STANDARD and STANDARD_IA.

If your bucket uses INTELLIGENT_TIERING or Glacier classes, Loki will reject it after the upgrade. Not “might”: will. And it fails on the write path, so your logs disappear fast, probably on a day you are busy with something else.

Before upgrading, check object storage classes with aws s3api list-objects-v2, or read the bucket lifecycle rules directly.

Defaults that moved

• Frontend encoding now defaults to protobuf (less bandwidth; verify any custom query frontend can decode it)
• Storage clients default to the Thanos set
• The ruler always wipes the remote-write WAL on startup
• The loki_log_flushes metric is renamed

The order I would upgrade in

With log systems, the real fear is “the upgrade finished and the history is unreadable”. So:

1. Read the migration guide and collect every removed key in limits_config. Loki fails at startup on unknown keys, which is helpful here
2. In an isolated environment, query chunks and indexes written by the old version. That is the only real compatibility test
3. Check S3 storage classes and lifecycle rules
4. Upgrade the read path (querier) before the write path (distributor, ingester)
5. Do the ruler last, and accept that it clears the WAL

Should you run it now

Not in production during RC. But if you are on the “must upgrade this year” list, now is the best time to walk the migration checklist. Problems reported during RC get fixed; problems reported after the final release get documented as known issues.

One last observation: major releases that delete features are frightening to read and usually safer than the ones that add ten new ones. Deleted code does not have bugs.