Should I upgrade to DuckDB 1.3 Base Image now?
Choose whether to upgrade container images, pin DuckDB older, or switch execution environments after DuckDB 1.3 raised the glibc floor to 2.28.
Blockers
- requires_version: package/duckdb-1-3 → runtime/glibc-2-28
- breaking_change_in: package/duckdb-1-3 → runtime/amazon-linux-2
- breaking_change_in: package/duckdb-1-3 → runtime/debian-10
- Lock-in via package/duckdb-1-2
- Lock-in via package/duckdb-1-2
Who this is for
- cost-sensitive
- low-ops
- serverless
Candidates
Upgrade container or runtime base images to glibc 2.28+
As of 2026-04-02, this is the default long-term path if you want current DuckDB releases on Linux. DuckDB's 1.3.0 announcement says official Linux binaries now require glibc 2.28 or newer because the release is built with Python's manylinux_2_28 image. Debian 11 ships glibc 2.31, while Amazon Linux 2023 ships glibc 2.34; Amazon Linux 2 remains on glibc 2.26. For teams on old base images or Lambda custom/container runtimes, the migration usually means moving from Debian 10 or Amazon Linux 2 class environments to newer images.
When to choose
Use this when you need native DuckDB on Linux, want to keep upgrading DuckDB normally, and can rebuild/test container images. It is the decisive option when your execution environment is under your control and you do not want to stay pinned to a pre-1.3 release.
Tradeoffs
Best forward compatibility and least vendor or product lock-in. The cost is image migration work, possible package-manager changes, and broader runtime regression testing.
Cautions
Do not assume only DuckDB changes: moving from Amazon Linux 2 to Amazon Linux 2023 also changes the package set and tooling, and Lambda's AL2023 images are the basis for newer managed runtimes. Check your native extensions, CI images, and deployment scripts before cutting over.
Pin DuckDB to 1.2.x or earlier on old glibc environments
As of 2026-04-02, pinning below DuckDB 1.3 is the lowest-disruption way to keep running on older Linux bases that cannot meet glibc 2.28. DuckDB 1.2.0 was released before the glibc floor change, while 1.3.0 is the release that raised the official Linux binary requirement. This keeps existing Debian 10 or Amazon Linux 2 style environments alive without an image migration. DuckDB remains open source, so the direct software cost is unchanged, but you are choosing an older feature line.
When to choose
Use this when the base image is effectively fixed in the near term, or when a fast operational unblock matters more than new DuckDB features. It is the decisive option for short-term containment while a broader OS or runtime migration is scheduled.
Tradeoffs
Fastest operational fix and usually the cheapest immediate path. The downside is deferred platform debt, delayed access to newer DuckDB features, and a longer tail of version-specific testing.
Cautions
This should be treated as a temporary hold rather than a strategic endpoint. DuckDB's release calendar says LTS starts with 1.4.0, so staying on 1.2.x avoids the glibc break but also leaves you off the LTS track.
Switch execution environment to DuckDB-Wasm for compatible workloads
As of 2026-04-02, DuckDB-Wasm is an official DuckDB client that runs in the browser via WebAssembly. The docs list the latest stable DuckDB WebAssembly client as 1.5.1, and state that it can run inside any browser on any device. This changes the problem from native Linux binary compatibility to browser/WebAssembly constraints. For lightweight analytics or embedded client-side use cases, that can avoid a container base-image migration entirely.
When to choose
Use this when the workload can move to browser or WebAssembly execution and does not require a native Linux DuckDB process. It is the decisive option when changing the execution model is easier than changing fleet base images.
Tradeoffs
Avoids native Linux image churn for suitable workloads and can simplify local or embedded usage. The tradeoff is a different execution model with browser limits instead of server/container limits.
Cautions
DuckDB-Wasm defaults to single-threaded execution, and the docs note WebAssembly memory limits of 4 GB with potentially stricter browser limits. It is not a drop-in replacement for heavier server-side ETL or long-running native jobs.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to DuckDB 1.3 Base Image now?"