By ByteBot
Effect-TS just entered Release Candidate. Version 4.0 is the biggest overhaul the library has seen — a rewritten fiber runtime, bundle sizes that collapsed from 70 kB to 20 kB for a typical program, and a unified package system that finally kills version mismatch hell. The team has declared no more broad breaking changes before stable. That makes right now the window: migrate your v3 apps without playing guinea pig.
The Runtime Rewrite Is Architectural, Not a Benchmark Chase
The fiber runtime was rebuilt from scratch. Not tweaked — rebuilt. The result is lower memory overhead, faster fiber execution, and simpler internals that are easier to debug when things go wrong in production.
The headline number is ~20x faster streams and batching. That matters most for server-side workloads doing heavy data processing, streaming APIs, or pipeline-heavy ETL. But the real payoff for most teams is subtler: STM (Software Transactional Memory) is now integrated into core. Shared-state concurrency without race conditions used to require pulling in extra packages. In v4, it’s a first-class primitive in the runtime itself.
Bundle Size: 70 kB to 20 kB
This is the one that will get frontend and edge developers to actually read the migration guide. A minimal program combining Effect, Stream, and Schema dropped from roughly 70 kB in v3 to about 20 kB in v4. That’s a 71% reduction.
Real-world results track. Developer Sandro Maglione documented migrating several production codebases — gzipped worker bundles fell from 900 kB to 779 kB. Not a contrived benchmark — production workers. If you’re running Effect on Cloudflare Workers, AWS Lambda, or any edge runtime where cold starts matter, this is your reason to move.
One Package, One Version Number
Effect’s package ecosystem was previously split across effect, @effect/platform, @effect/rpc, @effect/cluster, and a dozen more. Keeping them all on compatible versions was a tax every team paid silently. A minor bump in one package would break another. Hours wasted.
In v4, all ecosystem packages share a single version number and ship together. effect@4.0.0 and @effect/sql-pg@4.0.0 are always compatible because they’re always the same version. Previously separate packages have been merged into core, with things that lived in @effect/platform and @effect/rpc now living directly inside effect under new import paths.
17 Unstable Modules: Where Effect Is Betting
Not everything in v4 is locked down. Effect ships 17 experimental modules under the effect/unstable/* namespace — covering AI, HTTP, Schema, SQL, RPC, CLI, workflows, and clustering. These can break in minor releases. That’s the contract.
The upside: the stable core benefits from having a defined experimental zone. Teams building production systems get a clear line between what they can depend on and what they’re choosing to live with. Teams building AI agent infrastructure get early access to primitives that will graduate to stable as they mature. This is better design than either shipping everything as stable too soon or keeping experimental packages entirely separate.
Should You Migrate Now?
The honest answer depends on one thing: whether you’re using any deprecated v3 APIs.
If you’re not: migrate now. The RC is exactly designed for this. The API is locked, the team has said no broad breaking changes between RC and stable, and community projects have been running the beta in production for months. The migration guide is on GitHub and there’s an automated migration skill on skills.sh for the mechanical parts. Stable is targeting Q3/Q4 2026 — it’s close.
If you are using deprecated APIs: two breaking changes worth checking first. MessagePack encoding was removed — migrate to effect/unstable/encoding/SchemaBinary. And PgClient.fromPool was removed — use PgClient.make or PgClient.layer directly. Neither is a blocker, but both require deliberate changes.
Tom MacWright from Val Town was honest about it: “v4 seemed exciting but we haven’t migrated yet — we use some deprecated APIs and try to avoid beta releases in production.” That’s a legitimate position. But RC is not beta. The Effect team is explicitly inviting production teams to migrate because they want the stable release stress-tested against real workloads before it ships.
How to Start
The official migration guide is the right starting point. For context on what changed and why, the RC announcement post is thorough. If you want real-world numbers before committing, Sandro Maglione’s migration notes cover what actually changed in production codebases. The August RC updates post covers the most recent fixes and performance improvements heading into stable.
The window between RC and stable is short. If the bundle size gains matter to you, or if you want your codebase validated before stable drops and your team starts asking questions, now is the time to move.
