Actions26
- Delete Collection
- Get Collection
- Check Collection Exists
- Create Collection
- Update Collection
- Retrieve Point
- Retrieve Points
- Upsert Points
- Delete Points
- Update Vectors
- Delete Vectors
- Set Payload
- Overwrite Payload
- Delete Payload
- Clear Payload
- Batch Update Points
- Scroll Points
- Count Points
- Query Points
- Query Batch Points
- Query Points Groups
- Matrix Pairs
- Matrix Offsets
- Payload Facets
- Create Payload Index
- Delete Payload Index
Overview
The node provides an interface to interact with Qdrant, a vector search engine and database. Specifically, the "Batch Update Points" operation allows users to perform multiple update operations on points within a specified collection in a single request. This is useful for efficiently managing large datasets where multiple changes—such as upserting points, updating vectors, modifying payloads, or deleting data—need to be applied atomically or in bulk.
Common scenarios include:
- Updating metadata or payloads of many points after a batch import.
- Modifying vector embeddings for multiple points simultaneously.
- Cleaning up or resetting payload data across a subset of points.
- Combining several update actions into one request to reduce API calls and improve performance.
Practical example: A user has a collection of product embeddings and wants to update the vectors for a batch of products while also setting new payload attributes like price or availability flags. Using this operation, they can send all these updates in one go.
Properties
| Name | Meaning |
|---|---|
| Collection Name | The name of the collection in Qdrant where the batch update operations will be performed. |
| Operations | A JSON array listing the specific update operations to execute. Possible operations include: upsert, update_vectors, set_payload, delete_payload, delete_vectors, and clear_payload. Each operation defines what changes to apply to which points. |
| Wait | Boolean flag indicating whether to wait for the changes to be fully applied before returning. If true, the node waits for confirmation that updates have been processed. |
| Ordering | Defines the ordering guarantees for the batch update operation. Options are: Weak, Medium, Strong. This controls consistency and ordering semantics of the update requests. |
Output
The node outputs JSON data representing the result of the batch update operation. This typically includes status information about the success or failure of each individual operation within the batch. The output structure reflects the response from the Qdrant API for batch updates.
If binary data were involved (not indicated here), it would represent raw data such as files or images, but this operation deals primarily with JSON-based point data.
Dependencies
- Requires an active connection to a Qdrant instance, configured via credentials containing the base URL and an API key or token for authentication.
- The node depends on the Qdrant REST API being accessible and properly configured to accept batch update requests.
- No additional external services beyond Qdrant are required.
Troubleshooting
Common issues:
- Invalid collection name: Ensure the collection exists in Qdrant before attempting batch updates.
- Malformed operations JSON: The operations property must be a valid JSON array with correctly structured update commands.
- Authentication errors: Verify that the API key/token and base URL credentials are correct and have sufficient permissions.
- Ordering conflicts: Selecting a strong ordering guarantee may cause delays or failures if the backend cannot satisfy the consistency requirements.
Error messages:
- "Collection not found": Check the collection name spelling and existence.
- "Invalid operations format": Validate the JSON syntax and structure of the operations array.
- "Unauthorized": Confirm API credentials and access rights.
- "Timeout waiting for changes": If
waitis true, the operation might time out if the backend is slow; consider settingwaitto false or increasing timeout settings.