v1.6.4 — Vector storage & DB reliability fixes

Release Date: 2026-10-13
Changes: v1.6.3 → v1.6.4

Summary

This patch release fixes several backend issues around vector search adapters and the Turso database adapter, and removes an unwanted background pruning task for LanceDB-backed stores. The changes reduce memory use and errors during searches, make Turso open failures report consistently, and add tests and harness fixes to improve reliability.

Highlights

• Avoid returning the raw vector column during searches for LanceDB and pgvector adapters — reduces memory use and prevents failures.
• Turso errors raised during database open now surface as OperationalError so calling code can handle them consistently.
• Removed LanceDB background pruning to stop unexpected background work that could interfere with searches.
• Added tests and harness fixes to prevent intermittent subprocess/session failures and improve stability.

Breaking Changes

• Behavior change for LanceDB-backed datasets: automatic background pruning has been removed. If you relied on automatic pruning/compaction to reclaim storage space, you may need to run compaction or pruning manually (via LanceDB tooling or your existing maintenance processes). This is a behavioral change rather than an API incompatibility, but it may affect disk usage and maintenance procedures.

New Features

• No new end-user features in this release — this update focuses on bug fixes and reliability improvements.

Improvements

• LanceDB adapter: stopped selecting (returning) the raw vector column when performing vector searches. The vector column contains the numeric embedding for each item; excluding it from search results reduces network and memory usage and avoids returning large binary data that consuming code doesn't need during search.
• pgvector adapter: same change as above for PostgreSQL pgvector-backed datasets — searches no longer select the raw vector column, yielding the same memory and stability benefits.
• Turso dialect (database adapter): when opening a Turso database fails due to an I/O or underlying client error, Cognee now raises a SQLAlchemy OperationalError (a standard, catchable database error). This makes error handling consistent across database backends and lets calling code react to open failures reliably.
• Removed LanceDB background prunes: automatic background pruning tasks inside LanceDB-backed storage were removed to prevent unexpected background activity that could interfere with queries or tests. This reduces surprising concurrent work during searches and testing.

Performance

• Search queries against LanceDB and pgvector should use less memory and run with lower latency because the large vector column is no longer fetched unless explicitly requested.
• Reduced intermittent test/flakiness from subprocess/session failures thanks to harness fixes and added tests.

Security

• No security vulnerabilities or credential changes in this release.

Bug Fixes

• Fixed harness issues and added tests to cover subprocess/session failure scenarios, reducing intermittent CI/test failures.
• Fixed LanceDB and pgvector adapters to stop selecting the vector column during search (prevents large binary data from being returned and reduces memory/serialization errors).
• Raised Turso 'open' errors as OperationalError to avoid exposing low-level client exceptions directly to callers.
• Removed LanceDB background pruning logic that could run during operations and cause unexpected interference.

Technical Changes

• Cognee-MCP version bumped to 0.5.7 and lockfile updates synced to cognee 1.6.3 in the cognee-mcp/uv.lock file.
• Dependency upgrades in the lockfile include newer lancedb, lance-namespace, and pylance package versions.
• Various lockfile and packaging metadata updates (pyproject and uv.lock) were applied.
• Repository housekeeping: commit-author verification added and release chore commits for v1.6.4.

Compatibility

— The Cognee Team · 2026-10-13