Version history, new connectors, performance improvements, and breaking changes. Subscribe to get release notes in your inbox.
/v1/schemas to /v2/registry. Update your zipline.yaml and any direct API integrations before upgrading. The v1 endpoint will serve 410 Gone after 2026-06-01.
zipline estimate CLI command - predict monthly event volume from source database statistics before deploying. Shows per-table write rates, estimated egress, and projected cost. backward, forward, and full compatibility modes. Conflict alerts fire to PagerDuty and Slack webhooks. zipline status showing stale lag metrics for connectors that had been paused and resumed. When a Zipline connector was restarted while the Postgres source was under heavy write load, the previous replication slot was not reliably cleaned up before the new slot was created. In some topologies, this caused replication slot accumulation - up to one new slot per restart - which could block VACUUM and eventually cause disk exhaustion on the source database.
The fix adds a synchronous cleanup step before slot creation and a slot-count guard that alerts when more than 2 slots exist for the same connector name. Upgrading to v2.3.1 is strongly recommended for all Postgres source users.
max_replication_slots guard - connector now alerts and refuses to create more than 2 slots per connector name, preventing silent accumulation. zipline_connector and zipline_pipeline are deprecated in favor of zipline_source_connector and zipline_sink_connector. Old names will be removed in v2.5.0. Run zipline tf migrate to auto-update your HCL.
POST /v2/replay or zipline replay --from=2026-03-01 --to=2026-03-12. Replayed events are tagged with X-Zipline-Replay: true. _zipline_ts. zipline migrate --dry-run to preview all configuration changes. Allow 30–60 minutes for large deployments.
source/sink split. Pipelines now expressed as a directed graph with explicit edge declarations. /v2/. Old /v1/ endpoints return 410 Gone. All SDKs updated to 2.0.0. A detailed look at the WAL-to-sink transaction ID chaining that powers Zipline's exactly-once guarantees. We cover Kafka idempotent producers, checkpoint fencing, and what happens when a broker crashes mid-batch at 1.2M events per second.
ReadWhen Shopify needed to migrate 42 connectors from v1 to v2 without interrupting their Black Friday pipelines, we built a shadow-mode migration system. Here's how it works: dual-write, lag comparison, and the automated cutover that took 11 seconds per connector.
ReadAfter a customer's Postgres source ran out of disk space due to replication slot accumulation, we traced the issue through 14 layers of indirection. This post walks through our debugging process, the fix in v2.3.1, and how to detect slot leaks before they become incidents.
Read