How do Qdrant aliases let you swap in a rebuilt collection with no downtime?

## The problem aliases solve A Qdrant collection's vector size and distance are fixed at creation, so a new embedding model, a changed chunking strategy or a different metric all mean building a **new collection**. If your application hard-codes the collection name, the switch is a code deploy timed against a data load — and a rollback is another deploy. Aliases decouple the two. An alias is simply an alternative name that resolves to a collection. Anywhere the API takes a collection name — search, upsert, scroll, retrieve — it will accept an alias. Your service reads and writes `docs`; `docs` currently means `docs_v3`. ## The atomic switch Alias changes go through one call that takes a **list** of operations: ``` client.update_collection_aliases( change_aliases_operations=[ models.DeleteAliasOperation(delete_alias=models.DeleteAlias(alias_name="docs")), models.CreateAliasOperation( create_alias=models.CreateAlias(collection_name="docs_v2", alias_name="docs") ), ] ) ``` The operations in a single call are applied together. That is the whole point: doing the delete and the create as two separate calls leaves a window — however short — in which the alias does not exist and every query fails. Bundling them means a request either resolves to the old collection or to the new one. There is no third outcome to handle. The available operations are `CreateAliasOperation`, `DeleteAliasOperation` and `RenameAliasOperation`. You can inspect the current state with `client.get_aliases()` for all aliases or `client.get_collection_aliases(collection_name)` for one collection's, which is the first thing to check when someone asks which physical collection is live. ## The rollout sequence 1. Create `docs_v2` with the new vector configuration. 2. Load it — bulk upsert with deterministic ids, as a background job with no traffic on it. 3. Verify: exact point count against the source, collection status settled, and a recall check against a held-out query set. This is the step people skip and regret, because a new embedding model can produce a collection that looks fine on counters and is worse on relevance. 4. Optionally shadow-read: issue a sample of live queries against `docs_v2` explicitly and compare results with `docs_v1`. 5. Switch the alias in one call. 6. Keep `docs_v1` for a defined period. It costs storage; it buys an instant rollback. 7. Delete `docs_v1`. A collection can carry more than one alias, which lets you keep a stable `docs` for readers plus a pinned `docs_v2` name for the tools that need to address a specific generation. ## The writer problem The alias switch is atomic for readers; live writers need a plan of their own. If your ingest pipeline is writing continuously, points that land in `docs_v1` between your last sync and the cutover are lost from `docs_v2`. The usual answers are to dual-write to both collections during the migration window, to pause ingest briefly around the switch, or to run a catch-up pass over everything modified since the load started before flipping. Raising this unprompted is what distinguishes a senior answer — otherwise the alias story sounds cleaner than it is. ## Snapshots A snapshot is a point-in-time copy of a collection's data, produced on the node and written to that node's snapshot storage. - `client.create_snapshot(collection_name)` creates one. - `client.list_snapshots(collection_name)` enumerates them. - `client.recover_snapshot(collection_name, location=...)` restores from a snapshot, where the location is a file URI on the node or a URL it can fetch. - `client.delete_snapshot(...)` removes one. - `client.create_full_snapshot()` captures the whole storage rather than a single collection. The critical property is *point in time*: writes accepted after the snapshot are not in it. That is a feature for backup and a hazard for migration — recover a week-old snapshot and you are missing a week of ingest unless you replay it. Snapshots serve three jobs. **Backup and restore** is the obvious one. **Environment cloning** — snapshot production, recover into staging — gives you a realistic dataset without re-running embeddings, which is often the expensive part. **Migration** moves a collection between clusters or versions: snapshot, transfer, recover into a new collection name, verify, alias into place. In a distributed deployment, snapshots are taken per node and per shard, so a whole-collection restore means dealing with each shard's snapshot rather than one file; do not describe it as a single portable artifact for a sharded collection. ## Putting the two together The pattern to state in an interview: **snapshots create the copy, aliases decide who sees it.** A restore never overwrites live data in place — you recover into a new collection, check it, and then repoint the alias in one atomic call. The old collection stays until you are sure. Applied consistently, this makes both model upgrades and disaster recovery boring, which is the goal.