The biggest feature we shipped in June was a way to stop using us. Full collection export: every vector's original id, the float32 vector at its original dimension, and all metadata, written to a directory of parquet parts you can read with one line of DuckDB or pandas. No size caps, no row limits, no "contact sales for exports over X." Your data leaves the way it arrived — whole.
It took most of a week because export touches everything. The storage layer snapshots a consistent view even while writes are landing. A job orchestrator tracks export state so a request survives restarts, with a seven-day retention window before cleanup. The REST surface got job endpoints — create, poll status, fetch a manifest, download parts. The SDK wraps it all in one call: collections.export() with wait/no-wait shapes and a manifest-driven multi-part download, and the LangChain wrapper passes it straight through. If you'd rather not babysit a long export, we'll email you when it's ready.
Two small details I'm fond of. Every export lands with an EXPORT_README.md beside the data — what's in the directory, the dimension, the metric, the row count, and a read-it-back snippet — because an export you can't interpret six months later is landfill. And the sidecar files are underscore-prefixed, which sounds trivial until you learn parquet readers skip underscore files by convention, so read_parquet('out/') treats the directory as one clean table instead of choking on the README.
The whole thing shipped with an eight-scenario end-to-end suite that exports real collections and diffs the parquet against what was ingested — including the empty-collection case, which of course was broken the first time. If the export button doesn't work, it's not a feature, it's a screenshot. Ours works; the tutorial for it is in the docs.