If you self-host Langfuse for LLM observability, the version you run in production is about to get a major bump — and the safe move this week is to do nothing in production and everything in a sandbox.
Between July 23 and July 27, 2026, the Langfuse team cut four release candidates for server 4.0.0 — rc.0 and rc.1 on the 23rd, rc.2 on the 24th, rc.3 on the 27th. A stable 4.0.0 has not been tagged yet. The release notes describe the change that matters most for anyone running their own instance: v4 drops superseded Postgres and ClickHouse tables and flips a set of v4 environment defaults after promoting the events tables to a new ClickHouse migration. That is a destructive, one-way migration, not a rolling restart.
First, the version trap#
The single most common confusion here is worth clearing before anything else: Langfuse the server and Langfuse the SDK do not share a version number. The client SDKs — the package your application code imports to emit traces — have been on their own v4 line for a while. The v4.0.0 release candidates cut this week are for the self-hosted platform: the application you deploy, backed by Postgres and ClickHouse.
They are decoupled. A v4 SDK talks happily to a v3 server. Upgrading your pip install langfuse does not upgrade your deployment, and it does not force you onto server 4.0. If you only consume Langfuse as a hosted service, none of this touches you. This piece is for the people who run the box.
What actually breaks#
The headline is the schema. When the release notes say v4 drops superseded Postgres and ClickHouse tables, they mean the tables v3 depended on are removed as part of the migration. The practical consequence is the one that bites: you cannot roll back by pointing an old v3 image at the same database. Once the migration has run, the shape of the data has moved on. A major-version server upgrade that touches two datastores at once — Postgres for metadata, ClickHouse for the high-volume events — is exactly the kind of change you rehearse before you run it for real.
New in the RC line is additive, not urgent: feedback submission via the public API and an MCP tool, and mobile trace views. Good to have. Nothing there is worth jumping an RC in production to get.
A release candidate is an invitation to test against a copy of your data — not a cue to point your live tracing pipeline at it.
The decision, in one screen#
Langfuse's own guidance is explicit: hold off on v3→v4 migrations in production until a stable release is published. Take it. Here is the sequence for a solo team or a small platform crew:
- Stay on the latest v3 in production. It keeps getting fixes; there is no gap you need v4 to close today.
- Restore a recent backup of both Postgres and ClickHouse into a throwaway environment sized like production.
- Deploy the v4 RC there and run the migration. Time it on real-sized data — a migration that promotes the events table can be slow when ClickHouse is holding months of traces.
- Verify your dashboards, saved views, evals, and API integrations still resolve against the migrated schema.
- Wait for the stable
4.0.0tag, then cut over during a window, with the backup you already restored as your escape hatch.
The reason to do the rehearsal now, before GA, is that the one thing you cannot buy on cutover day is a migration you have already watched succeed. RCs exist precisely so you can watch it — on data that does not matter — while the stakes are zero.
Why this is on your radar at all#
ClickHouse acquired Langfuse in January 2026 as part of a $400M Series D, and the core stays open-source and self-hostable. The v4 work leaning on the ClickHouse side — a fresh events-table migration — is consistent with that. But the upgrade calculus does not depend on the corporate story. It is the same calculus for any major server release that ships a destructive migration: test on a backup, run stable in production, and let the release candidate earn your trust before it earns your data.
