When does a self-hosted Qdrant upgrade need outside help?
Many teams running self-hosted Qdrant handle routine upgrades in-house, usually with a staging cluster and a maintenance window. Outside help becomes worth considering when the change is larger than a single restart, when the team lacks someone who has run a rolling upgrade on the chosen deployment path, or when the cluster must stay supported after go-live without a dedicated platform owner. The triggers tend to fall into four groups. The first is security: a patch to the engine, the API layer, or the base image that closes an exposure your scanners flagged. The second is a feature the application now needs, such as a newer filtering or access option. The third is version drift, where nodes, staging, and production end up on different releases and the gap makes the next change risky. The fourth is an operator or Helm change, such as a new chart version, an operator update, or a change to storage class or resource settings that touches every pod. The open-source engine is free to self-host under the Apache-2.0 license, so the cost of an upgrade is labor and infrastructure, not a license fee. The labor includes planning, test runs against a copy of production data, the change itself, and verification. The infrastructure includes the spare capacity needed to run a parallel environment and to hold backups before the change. Ask any partner to separate these costs in the quote. One point changes the calculation early. The Qdrant installation docs state that the community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, and that the enterprise operator is part of Qdrant Private Cloud. If your production path is the community chart, a rolling upgrade under load needs more manual steps and a clearer rollback plan, which raises the case for an outside review before you begin. Before deciding, confirm three things in your own environment: which minor version each node runs today, whether your backups can be restored to the target version under the snapshot rules, and who on your team will own the cluster after the change. If any of those answers is unclear, a short scoped assessment usually shows whether the work fits in-house.
What a Qdrant upgrade and support engagement includes
An upgrade engagement moves a running Qdrant cluster to a target release without losing data or search quality. The cards below follow the order of work: review what is running, plan the change and its rollback point, protect the data, execute in staging and then production, verify, and hand over. Optional recurring support covers what follows go-live.
Current-state review
We record the Qdrant version in use, the deployment path (single node, Helm chart, enterprise operator or Qdrant Hybrid Cloud), the collection and shard layout, replication settings, and the access configuration including API keys, JWT use and TLS. The review shows whether the Helm chart is in use, since it lacks enterprise features such as zero-downtime upgrades. It also confirms storage is block-level SSD or NVMe, not a network file system.
Upgrade plan and rollback point
The plan names the target release, the compatibility path from the current version, and the order of node changes. It sets a rollback point: a verified backup and the version to return to if search results or health checks fail. Snapshot restores only work within the same or next minor version, so the plan must confirm that a backup taken now can be restored if the change is reverted.
Pre-change backup and restore test
Before any change, collection snapshots are taken on every node that holds shards and stored in a location separate from the cluster, such as S3-compatible storage. A restore test into a non-production cluster confirms the archive is readable and the collection loads. Full-storage snapshots apply only to single-node deployments, so the method depends on the topology found in the review.
Staging rehearsal
The same steps run first in a staging cluster built from production-like configuration, with comparable data volume where the client can provide it. The rehearsal records the commands, timings, and any node restarts, and it tests the rollback path. Findings from staging update the production runbook before the production window is agreed with the client.
Production execution
Production upgrades follow the approved plan, one node at a time where the deployment supports it. Engineers watch cluster state, shard status and replication during each step, and stop to roll back if a defined check fails. Clients should confirm change windows, on-call contacts and who approves a rollback before the window opens.
Post-upgrade search and health checks
Verification covers cluster health, shard and replica status, and collection counts against the pre-change baseline. Search checks run fixed reference queries with expected results and payload filters, so relevance and filtering can be compared before and after. Access checks confirm API keys and JWT permissions still behave as configured, and the results are kept as evidence.
Runbook and handover
The client receives a runbook describing the topology, the upgrade procedure, the backup and restore steps, the rollback procedure and the verification checks. A handover session walks the client's operations team through each step. Clients should ask for the runbook in their own document system so it stays current after the engagement ends.
Optional recurring support
A retainer can cover monitoring follow-up, patch reviews against new Qdrant releases, scheduled backup tests, and upgrades in later windows. Recurring effort depends on release frequency, cluster count and how often the client changes collections. Clients should ask for the response scope, the included upgrade count and what is billed separately before signing.
What drives the cost and duration of a Qdrant upgrade
This table lists the factors that most change how much work a self-hosted Qdrant upgrade takes and how long it runs. Read each row as a question to answer about your environment before asking for a quote, and note the reduction approach beside it. The main takeaway is that deployment path, cluster shape and the number of environments usually matter more than the raw size of the vector data.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Number of nodes and distribution | A distributed cluster uses Raft for topology and splits collections into shards, so each node must be upgraded and checked in turn while quorum holds. A single-node deployment has fewer moving parts but also no failover. | Confirm node count and replication factor early. Plan a rolling sequence and agree on health checks for each node before the first change. |
| Deployment path (Helm chart or enterprise operator) | The community Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, so upgrades on it need more manual steps, maintenance windows and rebalancing work by hand. | Confirm which path you run today and whether an enterprise operator is part of your plan. Scope the manual steps in writing if you stay on the Helm chart. |
| Data volume and snapshot size | Larger collections take longer to snapshot, copy, verify and restore. Snapshots are tar archives of a collection on one node, so size directly affects backup windows and rollback time. | Measure collection sizes before scoping. Agree on backup storage capacity, and confirm that snapshots can be stored in S3-compatible storage if that is your target. |
| Number of collections and shard counts | Each collection needs its own snapshot, compatibility check and smoke test. Shard layouts that do not match the node count add rebalancing and validation work. | Inventory collections, payload indexes and shard counts. Remove unused collections and keep shard counts a multiple of the node count where the docs recommend it. |
| Number of environments upgraded in sequence | Development, staging and production usually follow the same path, and each stage repeats backup, upgrade and verification. Skipping a stage raises the risk of production surprises. | Agree on the promotion order and reuse the same runbook and test scripts in every environment. Ask whether the work for each environment is priced separately. |
| Integrations that call the API | Applications, pipelines and search services that depend on response formats, client library versions or endpoints need testing after the upgrade and may need their own changes. | List every client, library version and endpoint in use. Agree on a regression test set that covers search results, filters and write paths. |
| Access control and audit logging to re-verify | API keys, JWT permissions per collection, TLS settings and JSON audit logs must still behave as before after the upgrade. Each control needs a test and evidence that it works. | Document current key types, JWT claims and log destinations. Ask for a checklist that confirms each control and keeps the output as upgrade evidence. |
| Size of the version gap | A large jump between releases means more changed behavior and more release notes to review. Snapshot restore is limited to the same or next minor version, so older clusters may need intermediate steps. | Record the current version and the target version. Confirm restore compatibility with the snapshot documentation before choosing the path, and ask for each intermediate step to be scoped. |
How a Qdrant upgrade moves from assessment to handover
The sequence turns an upgrade into a documented change with a tested rollback path, a verified result and a clear owner for the period after go-live. Each phase closes with a written output the client can check before the next phase starts.
Assess the current version and deployment
We record the running Qdrant version, deployment method (single node, distributed cluster, Helm chart or enterprise operator), storage layout, replication factor, collection list, snapshot and backup settings, and how clients reach the API. We also confirm whether the instance still runs with default settings, since a self-deployed Qdrant listens on all interfaces without authentication unless it has been configured otherwise. The output is an assessment record that names every item the change touches. The step is done when the client has reviewed and signed off that record.
Review compatibility and release notes
We compare the current version with the target release, which for this page is the latest release on GitHub, v1.19.2, published October 5, 2026. The review covers release notes, configuration changes, deprecated settings, client library requirements and the snapshot compatibility rule that restores work only between the same minor version or the next one. Any version path that needs an intermediate step is written down here. The output is a compatibility memo with a go or no-go recommendation and a list of client changes. Confirm the target version again on the day of the change.
Rehearse the upgrade in staging
We build or refresh a staging environment that matches production in topology, storage type and configuration, then run the full upgrade procedure against it. As part of the rehearsal we take a collection snapshot in staging and restore it into a clean target to prove the archive is usable. We also time each step and record every command, so the production runbook reflects what actually happened. The output is a rehearsal report and a runbook marked with the points that need a decision. The step is done when the restore test passes and the client accepts the runbook.
Execute the change in the production window
Immediately before the change we take a fresh backup of every collection in scope, store it in a location the change cannot modify, and confirm it can be read. We then apply the upgrade according to the approved runbook, one node at a time where the deployment supports rolling changes, and watch cluster health between steps. Where the Helm chart is used instead of the enterprise operator, we state in advance that zero-downtime behavior is not provided. The output is a change log with start and end times, the backup reference and any deviation. The step is done when all nodes report the target version and the cluster is healthy.
Verify collections, search and access
After the change we check that every collection exists with the expected vector configuration, point count and payload indexes. We run a fixed set of reference queries and compare the results with the pre-change baseline recorded in the assessment. We also confirm that admin and read-only API keys, JWT permissions and TLS settings still behave as documented, and that JSON audit logging records authenticated operations. The output is a verification record with pass or fail for each check. The step is done when the client has accepted every check or has agreed a documented exception.
Monitor and hand over to operations
We watch the cluster through an agreed monitoring period for memory use, disk growth, latency, error rates and replication health, and we review logs for unexpected restarts or client errors. Any follow-up fixes are logged and closed before the period ends. The period length is set in the written scope, not fixed here. We then deliver the final runbook, the verification record, the change log, a list of open items and the support model that applies after handover. The step is done when the client operations team signs the handover record.
How snapshot version limits shape the upgrade path
A snapshot taken before an upgrade is only a useful safety net if you can restore it to the version you plan to run. Qdrant snapshots from one cluster can be restored only to clusters running the same minor version or the next minor version. That single rule decides whether your backup is a rollback option, a migration input, or a dead end, so check it before you touch production. The type of snapshot matters as much as the version. Collection snapshots are tar archives of one collection on one node, so they can be taken and restored collection by collection. Full-storage snapshots work only on single-node deployments. If you run a distributed cluster, plan around collection snapshots and confirm, per collection and per node, that you have what you need to rebuild the data. Do not assume a full-storage backup exists just because the cluster is backed up.
Where snapshots are stored also affects recovery. Since v1.10.0, Qdrant can store snapshots in S3-compatible storage, which keeps backups off the same disks as the running nodes. Qdrant itself cannot run on object storage, so this option is for snapshot archives only. Decide early whether your backup target is in the same failure domain as the cluster, who holds the access keys to that bucket, and how long snapshots are retained. Those choices belong in your change plan, not in an incident review.
Version gaps change the plan. When your current release and target release are more than one minor version apart, a snapshot from the current cluster may not restore directly to the target. In that case you need an intermediate upgrade step or a planned migration that moves data into a fresh target cluster. Build the sequence of minor versions before scheduling a window, and treat each hop as its own change with its own backup and verification. Before any upgrade, confirm the exact path with the Qdrant release notes for your current version and each target version, along with the snapshot documentation for your deployment type. Record the versions in the change ticket, test a restore of a representative collection into a non-production cluster at the target version, and compare search results against the source. Your team or the partner you use should own that restore test, because a backup that has never been restored is an assumption, not a control.
Which upgrade tasks stay in-house and which a partner takes
This table compares each Qdrant upgrade task with the team that usually owns it and the skills it requires. Read it as a split: routine work that repeats on a known pattern can stay with your platform and search operators, while the first major move and recovery rehearsal are where a partner's rehearsed runbooks tend to help most. Confirm the split against your own staffing before you scope a retainer or a fixed-scope upgrade.
| Task | Who usually owns it | Skills required |
|---|---|---|
| Upgrade planning and version path | Search platform lead with partner review for major moves | Qdrant release notes reading, snapshot compatibility rules, change planning |
| Snapshot and restore testing | Partner for the first rehearsal, then in-house on a schedule | Snapshot handling, storage access, restore verification on a separate cluster |
| Kubernetes rollout and rollback | Platform engineering team, partner for cluster-specific changes | Kubernetes workloads, Helm or operator configuration, StatefulSet behavior |
| Raft cluster health and shard checks in distributed mode | Search operations, with partner support during the first upgrade | Raft consensus concepts, shard and replica inspection, quorum awareness |
| Access control and audit log verification | Security engineering, confirmed after each change | API key and JWT configuration, audit log review, per-collection permission testing |
| Application regression testing of search results | Application team that owns the search feature | Query and filter test design, relevance baselines, result comparison |
| On-call response after change | Internal on-call rotation, with a documented escalation path | Incident handling, rollback decisions, log and metric triage |
| Release tracking | Platform team, reviewed monthly | Monitoring the GitHub releases page, assessing patch and minor version impact |
What goes wrong in Qdrant upgrades and how to prevent it
Most Qdrant upgrade incidents trace back to a small set of assumptions: that a snapshot will restore anywhere, that a cluster tolerates a node loss mid-change, or that a chart rollout keeps serving traffic. Each card below names one failure, why it matters for a self-hosted deployment, and the check to run before the change window opens.
Snapshot cannot restore to target version
Qdrant snapshots from one cluster restore only to clusters on the same minor version or the next minor version. A backup taken on an older release can be unusable as a rollback path after a multi-step upgrade. Before you upgrade, confirm the snapshot version against the planned target, and plan intermediate steps where the gap is larger than one minor version. Test a restore into a staging cluster on the target version.
Cluster upgraded without a quorum check
Qdrant distributed mode uses Raft for cluster topology and collection structure, so losing quorum during a node restart can block changes or stall writes. The distributed deployment docs recommend at least three nodes for production so quorum survives a single node failure. Before restarting any node, confirm that the cluster is healthy and that the remaining nodes hold a majority. Restart one node at a time and wait for it to rejoin before moving on.
Shard count not a multiple of node count
When the shard count is not a multiple of the node count, some nodes hold more shards than others and receive a disproportionate share of search and indexing load. This imbalance often appears only after an upgrade or a node is added, when the team expects an even spread. Check the shard layout per node after every topology change, and align the shard count with the node count when you create collections, since the docs recommend a multiple.
Helm chart rollout assumed zero downtime
The community Helm chart does not include enterprise features such as zero-downtime upgrades and automatic shard rebalancing. A standard rolling update can still restart pods that hold shards that are not yet replicated elsewhere, causing query errors or slow responses. Confirm the replication factor, check whether your traffic tolerates brief disruption, and schedule the rollout in a low-traffic window unless you have a tested plan for shard handling.
Storage on unsupported network file systems
Qdrant requires block-level storage with a POSIX-compatible file system. It cannot run on network file systems such as NFS, or on object storage such as S3 for live data. A volume that works on the old version can behave differently after a storage class change or a node pool rebuild, so verify the storage type of each persistent volume before and after the change. Use SSD or NVMe-backed block storage as recommended in the installation docs.
Secured settings lost during the change
By default, self-deployed Qdrant instances listen on all network interfaces and have no authentication configured. An upgrade that replaces the configuration file, the Helm values or the container arguments can silently drop API keys, TLS settings or interface bindings that were applied by hand. After each change, confirm that unauthenticated requests are rejected, that the expected interfaces are bound, and that TLS is active on REST and gRPC.
No tested rollback point
A rollback needs a snapshot that was taken before the change, stored outside the cluster, and proven to restore on the version you are returning to. Teams that skip this step discover the gap only when an upgrade fails under load. Take collection snapshots immediately before the change, store them in a location that survives node loss, such as S3-compatible storage, and record the restore procedure and the expected time to restore in the change ticket.
How Qdrant upgrades differ by starting point and environment
A single-node deployment is the simplest upgrade path because one process, one storage volume and no shard placement need to be coordinated. It is also the only topology where full-storage snapshots are available, so the pre-upgrade backup can cover the whole node. The plan centers on a complete snapshot taken while the node is healthy, a test restore into a separate instance and a documented rollback target.
- Snapshot scope: Full-storage snapshots cover the entire node, so confirm where they are stored, who can read them and how long you keep them.
- Version path: Restores work only within the same minor version or the next one, so plan any larger jump through intermediate releases and check each step against its release notes.
- Downtime window: The node is unavailable during restart, so agree the window with application owners and confirm how clients retry failed requests.
- Storage check: Confirm the volume is block storage with a POSIX-compatible file system, because network file systems and object storage are unsupported.
- Access settings: Re-verify API keys, TLS and network binding after the change, since a freshly written configuration can drift from the one you tested.
Before approving the change, confirm that a restore of the pre-upgrade snapshot completes on a separate instance and that search results match an agreed sample of queries.
A distributed cluster on Kubernetes adds shard placement, replica synchronization and quorum to the upgrade. The community Helm chart is a documented production path, but Qdrant's installation documentation lists zero-downtime upgrades and automatic shard rebalancing among the enterprise features it lacks. The plan therefore moves one node at a time, waits for the cluster to report healthy replicas and treats each step as a checkpoint.
- Node order: Upgrade one node at a time and wait for replicas to resynchronize before moving to the next pod.
- Quorum floor: Keep at least three nodes, the minimum that Qdrant's distributed deployment documentation recommends for production, so quorum survives a node loss during the window.
- Snapshots: Take collection snapshots for each affected collection, because full-storage snapshots are available only on single-node deployments.
- Chart pinning: Pin the chart version and image tag, and review the values diff before every upgrade.
- Shard balance: Since automatic rebalancing is absent from the chart, check shard distribution by hand after each change and before reducing capacity.
Before approving the change, confirm that the chart release notes for your target version match the steps in your runbook and that a full rehearsal ran on a staging cluster.
The enterprise Kubernetes operator is offered as part of Qdrant Private Cloud, a dedicated and fully isolated deployment. Qdrant's installation documentation lists zero-downtime upgrades among the enterprise features missing from the community chart, so the operator path changes what the rolling plan has to prove. Upgrade entitlement, support scope and the exact upgrade mechanics are set in your agreement with Qdrant, and those terms come first in the plan.
- Entitlement: Confirm with Qdrant which versions your agreement covers and what support you receive during an upgrade.
- Client inputs: Provide the Kubernetes clusters, storage classes, namespaces, network policies and a named change owner.
- Traffic verification: Test client retries and latency during a rolling update, even when the operator is documented to avoid downtime.
- Snapshot coordination: Confirm how collection snapshots are scheduled and stored alongside operator-managed upgrades.
- Rollback limits: Confirm with Qdrant whether downgrades are supported and which snapshot versions can be restored after a rollback.
Before approving the change, confirm the upgrade procedure in writing with Qdrant and rehearse it in a non-production Private Cloud environment.
Qdrant Hybrid Cloud runs managed Qdrant clusters on your own infrastructure, so the upgrade plan spans two responsibility lines: the managed service and the infrastructure you control. Pricing and service terms come through Qdrant sales, and the split of upgrade duties should be written down before go-live. The plan must also address the capacity, network paths and storage locations that you own.
- Responsibility split: Confirm in writing which upgrade tasks Qdrant performs and which tasks your team performs in its own accounts.
- Client inputs: Provide cloud accounts, Kubernetes capacity for surge pods during a rolling change, network egress rules and approved change windows.
- Headroom check: Verify that spare memory and SSD capacity can absorb a replica moving during the upgrade, taking the replication factor into account.
- Backup location: If snapshots go to S3-compatible storage, a option supported since v1.10.0, confirm bucket access, encryption and retention in your account.
- Restore compatibility: Confirm that snapshots from the current minor version restore into the target version, since restores are limited to the same or next minor version.
Before approving the change, run a restore drill into a separate Hybrid Cloud environment and confirm the responsibility split with Qdrant in writing.
Air-gapped and restricted networks cannot pull release artifacts during the upgrade, so every image, chart, binary and checksum must enter through your approved import process before the change window opens. The plan adds provenance and scanning steps that connected environments can often skip, and it keeps the snapshot store inside the restricted boundary. Release notes must also be reviewed on an approved machine before import.
- Artifact intake: Bring in container images, Helm charts or binaries, along with published checksums, through your transfer and approval workflow.
- Verification: Compare checksums and any published signatures against the source before the artifact reaches a build or registry system.
- Scanning: Run your image and dependency scanners on the imported artifacts, and record any exceptions for your security team.
- Internal registry: Mirror approved images into your internal registry and point chart values there, with no fallback to public sources.
- Snapshot storage: Keep snapshot targets inside the restricted network, and confirm that any S3-compatible store is internal.
Before approving the change, confirm that every artifact in the upgrade manifest has a recorded checksum, approval and scan result, and that a restore drill completed inside the restricted network.
What you need to provide before a Qdrant upgrade or support contract starts
Before we quote an upgrade or a support contract for self-hosted Qdrant, we need the inputs below in writing. Missing items are the most common cause of scope changes, because each one changes the plan for the upgrade path, the rollback path or who approves a change. Please confirm each item by email before the quote is issued, and tell us where an item does not exist yet so we can scope the work to include it.
Start with the technical baseline. We need read access to the cluster configuration and the deployment manifests, whether those are Helm values, a Qdrant operator custom resource or hand-written Kubernetes objects. We also need the exact running Qdrant version and edition, including whether you run the community Helm chart or the enterprise operator from Qdrant Private Cloud, because the chart does not include features such as zero-downtime upgrades. Please include the storage class and volume type behind each node, since Qdrant requires block storage with a POSIX-compatible file system and does not run on NFS or S3-backed volumes.
Next, describe the data and the consumers. Provide a list of collections with their vector counts, vector dimensions, payload size estimates, replication factor and shard count, and confirm which collections carry the most traffic. List every API consumer and integration that calls Qdrant, including batch jobs, embedding pipelines and any service that uses a read-only key. For each consumer, state whether it tolerates a brief write pause during the change window. This list determines the test cases in the staging run and whether a rolling upgrade is acceptable for each collection.
Third, confirm the environments and the recovery path. We need a staging environment that mirrors production in topology, node count, storage class and security settings, so that the upgrade can be rehearsed before it touches live data. Name the backup target, either local storage on the cluster or an S3-compatible bucket, and confirm who holds its credentials. Snapshots only restore to clusters on the same minor version or the next minor version, so the rehearsal must start from the version you run today. Also provide an approved change window, the named owners who sign off on application behavior, and the on-call contacts who respond during and after the change.
Finally, state the security requirements. Confirm how API keys are issued and stored, whether TLS is required for REST and gRPC, which certificates and key management service the cluster uses, where JSON audit logs are sent and how long they are kept, and whether any JWT-based access control must be preserved. Qdrant ships open by default, so we need to know which of these controls are already in place and which must be part of the work. Return the completed list to your DeployOpen contact, and we will issue the written scope against these confirmations.
Questions buyers ask before hiring a Qdrant upgrade partner
How is the cost of a Qdrant upgrade partner set?
The cost follows from a written scope. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ask the quote to separate one-time work (upgrade plan, rehearsal in a non-production copy, cutover, verification and runbook) from recurring work (a support retainer, if you choose one). Ask which cluster topology, collection count, data volume and version path the quote assumes, and what happens if the rehearsal finds a blocker. Staging infrastructure and backup storage are paid to your own cloud or data center provider, not to the partner, so ask for those costs to be listed separately.
What makes a Qdrant upgrade take more effort?
The biggest drivers are the deployment path, the cluster shape and the number of version steps between your current release and your target release.
Key drivers:
- Deployment path: the community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so the upgrade method differs by path.
- Cluster shape: distributed clusters with replication need a rolling sequence and shard health checks before each step.
- Snapshot compatibility: Qdrant snapshots restore only to clusters on the same minor version or the next one, so a jump across several minor versions usually needs staged steps.
- Data volume and collection count: larger collections take longer to back up, restore and verify.
- Integrations: every client, pipeline or filter that depends on API behavior adds test work.
Can our own team upgrade self-hosted Qdrant without a partner?
Yes, if your team has Kubernetes and search operations skills and has tested backups it can restore. The open-source engine is free to self-host, so an internal team can run the upgrade on its own infrastructure.
The skills that matter most are operating Kubernetes workloads, understanding Qdrant's storage needs (block storage with a POSIX-compatible file system, with SSD or NVMe recommended), and proving that a snapshot restores to the target version before the production change. A partner can add value in planning, rehearsal and cutover review, or be asked to write the runbook and test queries. Confirm your team's skills and backup restore results before deciding who runs the change.
How long does a Qdrant upgrade project take?
The duration depends on the scope, and the written plan sets it. No single timeline applies to every Qdrant environment, so treat any generic number with caution.
The factors that set the length are the number of environments, cluster size, data volume to back up and restore, the number of version steps, the number of applications that must be tested, and the change windows your organization allows. Ask the partner to show the milestones in the plan: assessment, backup and restore proof, rehearsal in a non-production copy, production change window, and post-upgrade verification. Each milestone should name the owner and the evidence it produces.
Does the open-source Qdrant engine have a license fee?
No. The Qdrant engine is licensed under Apache-2.0 according to its GitHub repository, and the open-source engine is free to self-host.
The cost of running it yourself is therefore labor and infrastructure. Labor covers planning, upgrading, testing, monitoring and incident response by your staff or a partner. Infrastructure covers compute, memory, SSD or NVMe block storage, backup storage (including S3-compatible storage if you use it for snapshots), and any staging environment you keep for rehearsals. Qdrant Cloud, Hybrid Cloud and Private Cloud are priced separately through Qdrant's pricing page and sales team.
Does Qdrant Cloud remove the need for upgrades?
Managed hosting changes who runs the upgrade, but it does not remove the need to plan around version changes. Confirm the details with Qdrant before you decide.
Ask Qdrant about the tier you would buy, the uptime terms in its service agreement, how and when it applies upgrades, how much notice you receive, and whether the tier includes features you rely on, such as SSO or private VPC links. Qdrant's pricing page lists a 99.5% uptime SLA for the Standard tier and a 99.9% uptime SLA for Premium, but you should read the full terms. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure, so you still own part of the upgrade path there.
What does our team need to provide for a Qdrant upgrade?
Your team provides access, facts about the current system and named decision makers. Missing any of these usually adds time to the plan.
Typical inputs:
- Access to the non-production and production clusters, Kubernetes namespaces and backup storage
- The current Qdrant version, deployment configuration and collection inventory with sizes
- Evidence of recent backups and a restore test, if one exists
- Application test queries with expected results, including filtered searches
- Named owners for approvals, change windows and rollback decisions
- A non-production environment that resembles production in topology and data volume
Confirm these items in the written scope so the plan can name what it assumes.
What does ongoing Qdrant support cover after go-live?
Ongoing support is available as a retainer, and its scope is set in the written agreement. Ask for the list of covered tasks, the response terms and what is excluded before you sign.
Typical areas include planning and running future upgrades, patching, reviewing monitoring and capacity, verifying backups by restoring them on a schedule, and responding to incidents within the agreed terms. DeployOpen also runs security testing, which you can add to a retainer for continuous testing of the deployment. Ask how changes to access controls, API keys, TLS or audit logging are handled, and who approves them.
How DeployOpen scopes, delivers and supports Qdrant upgrades
DeployOpen plans, performs and documents self-hosted Qdrant upgrades inside your own infrastructure, starting from a written scope and a verified backup. Engagements are fixed-scope, and ongoing support can be added as a retainer once the cluster is live.
How we scope
- The written scope names the current and target Qdrant versions and confirms the upgrade path between them.
- We inventory deployment type, whether single-node or distributed, and how snapshots are produced and stored.
- The scope states which environments are covered, such as staging and production, and who approves each change.
How we build
- We rehearse the upgrade in a non-production copy of the cluster before any production change is made.
- We verify snapshot compatibility against the target minor version before the upgrade window is planned.
- Kubernetes rollouts are tested for node-by-node behavior, with search results checked before and after each step.
How we hand over
- You receive a runbook covering backup, rollback, upgrade steps, and the verification checks used at each stage.
- Backup and restore results from the rehearsal are documented so your team can repeat the procedure.
- Handover includes a record of configuration changes, version history, and open items for your operations team.
How we support
- Ongoing support is available as a retainer and can cover planned upgrades, patch reviews, and backup checks.
- Support scope, response expectations, and included upgrade work are written into the retainer agreement before it starts.
- Confirm with your team which Qdrant release notes and security advisories should trigger a review under the retainer.
