Point IDs identify records, not vector semantics
Qdrant point IDs are supplied by the application and can be either 64-bit unsigned integers or UUIDs. The ID is the stable identifier used to address, update, retrieve, and delete a point; it does not determine vector similarity.
The choice should follow the identity model of the source system. Numeric IDs can be compact and convenient when the source database already uses numeric identifiers. UUIDs are often easier when identifiers are globally unique across services or generated before persistence.
The trade-off is mainly interoperability and operational simplicity. A UUID avoids coordination for distributed ID generation, while a numeric ID can be smaller and easier to integrate with existing systems. Do not use an embedding hash as an ID merely because it is deterministic unless that identity semantics is actually what you want.
A common mistake is treating the Qdrant ID as an internal auto-increment key. The application owns the identifier, and it should remain stable if the same logical entity is re-indexed.
Qdrant accepts 64-bit unsigned integer IDs or UUIDs
IDs are application-level identities and do not encode similarity
Stable IDs make upserts and synchronization predictable
Choose the ID scheme based on source-system identity and distributed-system requirements
Your source database uses integer product IDs. Would you generate a second random ID in Qdrant? Why?
A document is reprocessed every night and receives a different Qdrant ID each time. What problem will this cause?
Two ingestion workers can create the same document concurrently. How would you choose an ID strategy to make repeated writes safe?
You need to synchronize deletes from a relational database to Qdrant. Why does stable point identity matter?
Your platform merges records from five source systems whose numeric IDs can overlap. How would you design globally stable Qdrant IDs?
A migration changes IDs from integers to UUIDs while search traffic continues. How would you avoid duplicate or missing records?
You operate a multi-region indexing platform where entities can be created independently. What ID-generation and reconciliation strategy would you use for Qdrant?
A downstream system treats Qdrant point IDs as public API identifiers. What architectural concerns would that create, and would you keep that coupling?