SQLAlchemy pool with DuckDB dialect: diagnosing intermittent exhaustion across forked workers

Setup

I am running DuckDB (assume v0.10.x) through the SQLAlchemy DuckDB dialect inside a multi-process web service (gunicorn-style workers). Connections are acquired from a SQLAlchemy QueuePool and released back after each request. Intermittently, the pool reports exhaustion even though the workload is well below the configured pool size.

Constraints and uncertainty

DuckDB connections are in-process handles with no server-side limit, so exhaustion must come from the client pool or unreleased references. Two behaviors make this hard to pin down: the DuckDB Python module can keep a native connection alive until all derived cursors are released, and uncommitted transactions are silently rolled back on close(), which may hide application-level leaks. Additionally, each forked worker inherits its own DuckDB state, so a pool sized for the parent process may not match per-worker reality. I also understand the dialect may not enable pool_pre_ping by default, raising the question of whether stale connections after a fork are being counted as live.

Questions

• When using the SQLAlchemy DuckDB dialect with forked workers, should the engine and pool be created per worker after fork, and does the dialect document any fork-safety guarantees?
• Does DuckDB's silent rollback of uncommitted transactions on close() affect when the native handle is actually released back for reuse, and is this consistent across v0.9 and v0.10?
• Is enabling pool_pre_ping meaningful for an embedded engine like DuckDB, or is connection liveness purely a client-side reference-counting concern?