Shared DuckDB database file compatibility across mixed engine versions

Teams that share a single DuckDB database file across Python, R, and CLI environments face a storage-format compatibility policy decision. Because DuckDB is embedded, each environment bundles its own engine version. The v1.0.0 release is documented to introduce a stable storage format commitment for files created by that version and later, but opening a file written by a newer release with an older client is expected to raise an error rather than degrade gracefully. This leaves an unresolved design decision for mixed-version access.

The core uncertainty is whether to pin one DuckDB version across all readers and writers, or to standardize interchange on Parquet/CSV so the engine version and file format remain decoupled. Additional constraints include the possibility that a newer writer may upgrade the file in place, and the separate locking rules that apply when multiple processes access the same file.

Should a single DuckDB version be pinned across every environment touching the shared file, or is a decoupled interchange format more appropriate for mixed-version workflows? If a newer engine writes to the file in place, what migration path is supported when an older client must still read it? How can current storage-format compatibility boundaries be confirmed for the specific versions deployed in each environment?