Wren v0.14 turns semantic-model deployment and memory footprint into explicit operating choices

Wren AI’s newly published v0.14.0 is not a headline-grabbing text-to-SQL model upgrade. It is a release about the machinery around the model: how teams move semantic projects, package retrieval memory and prevent stale state from leaking into production behavior. The release notes list two features and three fixes, all in the wren core.

Git becomes the deployment boundary

The new wren cloud commands let an operator create, link or unlink a local directory from a Wren Cloud project. The implementation describes that binding as a Git remote: after setup, ordinary git push and git pull move the project, while separate authentication commands store or remove the credential used by Git. The feature commit explicitly says the authentication operation does not touch the working directory.

For practitioners, that makes reviewable version control—not a proprietary upload action—the handoff between local semantic-model work and the hosted service. That is an architectural advantage only if teams apply the controls they already use for code: protected branches, peer review, credential rotation and a clear promotion path. The release does not claim to supply those organizational controls; it supplies the transport primitive.

Memory no longer has to drag in Torch

Wren memory also gains an optional ONNX embedding backend. Its implementation commit adds a CI job that fails if the ONNX installation pulls in Torch, Triton or NVIDIA packages. The commit explains why: on Linux x86-64, the sentence-transformers path can resolve a CUDA build plus a large accelerator dependency set. A separate parity test installs both backends and checks that stores written by one remain readable by the other.

That is more than package tidiness. A smaller, CPU-oriented dependency option can simplify container builds and reduce the software surface operators must patch. The compatibility test is equally important: an alternative embedding runtime is much less useful if switching runtimes silently invalidates accumulated query memory.

Two fixes close persistent-state traps

The release changes the Microsoft SQL Server connector to use autocommit. The connector patch says PyODBC otherwise leaves Wren’s cached, long-lived connection inside a transaction that is never committed.

A second memory-sync patch adds provenance tags so reindexing deletes only query-history rows created by the Markdown synchronizer, while preserving user-stored rows that may share a generic source label. Together, the fixes address two different kinds of stale state: database transaction state and retrieval-memory state.

The practical upgrade test is therefore broader than “does SQL still generate?” Teams should verify Git promotion and rollback, compare memory results across the default and ONNX backends, test SQL Server writes on long-lived connections, and confirm that deleting a Markdown knowledge example removes that example without erasing unrelated user memory.