When Qdrant Cloud or self-hosted Qdrant fits your team
Choose Qdrant Cloud when your team wants the vector database running without staffing a cluster, and choose self-hosted Qdrant when your data, network or Kubernetes skills require it to run inside your own infrastructure. The open-source engine is Apache-2.0 licensed and free to self-host, so the decision is about who operates the cluster and where the data sits, not about license cost. Qdrant Cloud fits teams that want managed horizontal and vertical scaling, automatic shard rebalancing, backups and zero-downtime version upgrades on highly available clusters. Those features are the ones a self-hosting team has to build or run by hand, so the cloud option removes that operating load in exchange for a usage-billed or minimum-spend subscription. The free cloud tier, a single-node cluster with 0.5 vCPU, 1 GB RAM and 4 GB disk, is meant for testing and prototypes, not for production traffic.
Self-hosting fits when vector data must stay in your network, when your security or regulatory rules rule out a managed service, or when you run air-gapped networks. It also fits teams that already operate Kubernetes and storage well. Be aware of the prerequisites: Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3-style object storage, and the defaults are not secure, since a fresh instance listens on all interfaces with no authentication. Plan API key setup, TLS and network policy before the first deployment. Qdrant documents three production paths: managed cloud, a community Helm chart and an enterprise Kubernetes operator that ships with Private Cloud. Ask whether your team needs the operator, because the community Helm chart does not include zero-downtime upgrades or automatic shard rebalancing.
Hybrid Cloud and Private Cloud sit between the two. Hybrid Cloud runs managed Qdrant clusters on infrastructure you own, with data staying in your network, which suits teams that want managed operations under their own controls. Private Cloud is a dedicated, fully isolated enterprise deployment aimed at strict security, compliance and air-gapped needs. Both are priced through Qdrant sales, so the quote is the only reliable source of cost, and you should ask for the exact components, support terms and upgrade process in writing before comparing them with self-hosting. Confirm the cloud provider regions and deployment targets you need, since the public pricing page names AWS, Azure and GCP for Standard and Premium clusters. DeployOpen can plan and run a self-hosted deployment in your environment under a fixed scope; it does not resell Qdrant Cloud or Hybrid Cloud.
How the two models differ on license, tiers, scaling and uptime
This table sets Qdrant Cloud tiers against running the Apache-2.0 engine yourself, row by row on license, billing, uptime, upgrades and scaling. Read each row as a question to confirm with Qdrant for your own sizing, since the researched facts do not give Standard or Premium prices.
| Factor | Qdrant Cloud | Self-hosted Qdrant OSS |
|---|---|---|
| Engine license | Managed service on the same engine, with terms set by Qdrant's commercial agreement | Apache-2.0 licensed and free to self-host, per the Qdrant repository |
| Free tier | Single-node cluster with 0.5 vCPU, 1 GB RAM and 4 GB disk, aimed at testing and prototypes | No tier limit, but you size and pay for your own servers, storage and staff time |
| How usage is billed | Hourly for vCPU, memory, storage, backup storage and paid inference tokens; confirm current rates on the pricing page | Infrastructure cost on your cloud or data center accounts, plus engineering time to run it |
| Standard tier uptime | Usage-priced tier with a 99.5% uptime SLA and dedicated resources with high availability | No vendor SLA; uptime depends on your cluster design, monitoring and on-call process |
| Premium tier | Minimum-spend tier with SSO, private VPC links and a 99.9% uptime SLA; confirm the minimum with Qdrant | SSO and private networking are yours to build with your identity and network teams |
| Upgrades | Easy version upgrades with zero downtime on highly available clusters | Zero-downtime upgrades are an enterprise operator feature; the community Helm chart does not include them |
| Shard rebalancing | Automatic shard rebalancing as the cluster scales | Rebalancing and resharding are handled by hand in a self-hosted distributed cluster |
| Hybrid and Private Cloud | Hybrid Cloud runs managed clusters in your infrastructure; Private Cloud is dedicated and isolated; both are quoted through Qdrant sales | Full control in your own network, including air-gapped sites, without a vendor-managed control plane |
| Cloud providers | Standard and Premium clusters run on AWS, Azure and GCP | Runs on any infrastructure that provides block storage with a POSIX-compatible file system |
Where your data lives and what compliance teams must prove
Where Qdrant data sits depends on the deployment model you pick, and so does the evidence your compliance team has to produce. The cards below cover data location, the access controls built into the engine, the insecure default state of self-deployed instances and the boundary between what DeployOpen prepares and what independent auditors issue.
Data location under each model
Qdrant Cloud runs on AWS, Azure or GCP, so vectors and payloads sit in a provider region you select. Hybrid Cloud runs managed clusters on your own infrastructure with data staying in your network, and Private Cloud is a dedicated, isolated deployment for strict security and air-gapped needs. Self-hosting keeps every byte in your environment. Confirm the regions, subprocessors and backup locations in writing before you sign.
API keys and TLS in the engine
The open-source engine supports admin and read-only API keys, and TLS for REST and gRPC since v1.2.0. These controls are yours to configure and rotate on self-hosted clusters, and you must also manage certificate issuance and renewal. Check that clients only reach the endpoints you intend, and record who holds each key.
Per-collection JWT permissions
JWT-based access control with per-collection read or write permissions arrived in v1.9.0. This lets you separate ingestion services from retrieval services and limit each to the collections it needs. Map these roles to your identity model before go-live, because the engine enforces the grants but does not decide who should hold them.
JSON audit logs of API calls
JSON audit logging of authenticated API operations has been available since v1.17.0. Route these logs to your SIEM and set retention to match your evidence obligations, since the engine records operations but does not decide how long you keep them. Test that a sample write and a sample search both appear with the caller identity attached.
Insecure by default when self-deployed
The security docs state that self-deployed Qdrant instances listen on all network interfaces and have no authentication configured by default. A fresh self-hosted node is therefore reachable and open until you add API keys, TLS and network restrictions. Make hardening a gated step in your deployment pipeline and scan for exposed ports. Managed Qdrant Cloud removes this setup task, but you still need to confirm how the provider configures access.
Evidence DeployOpen prepares, not issues
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, access design and logging setup. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Ask each provider for its current attestation reports and confirm their scope with the vendor before you rely on them.
Which features each deployment model gives you
Qdrant Cloud is the option where the vendor operates the cluster on AWS, Azure or GCP. The Qdrant Cloud documentation lists horizontal and vertical scaling up and down, automatic shard rebalancing, backups and disaster recovery, and easy version upgrades with zero downtime on highly available clusters. Those are the features a self-hosted team has to design, script and test on its own.
- Scaling: Horizontal and vertical scaling are offered as cluster operations rather than manual node provisioning.
- Rebalancing: Shards are redistributed automatically when the cluster changes.
- Upgrades: Version upgrades are documented as zero-downtime on highly available clusters.
- Backups: Backup and disaster recovery are part of the managed offering, with the tier determining the uptime commitment.
- Billing: Charges are hourly for vCPU, memory, storage, backup storage and paid inference tokens.
Before relying on these features, confirm in writing which backup retention, restore process and availability terms apply to the tier you select.
Qdrant Hybrid Cloud runs managed Qdrant clusters on your own infrastructure, with data staying inside your network. Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment aimed at strict security, compliance and air-gapped needs, and it is the home of the enterprise Kubernetes operator. Both are priced through Qdrant sales, so the operational feature set depends on what the contract includes.
- Data location: Hybrid Cloud keeps vectors and payloads in your network while Qdrant manages the cluster.
- Isolation: Private Cloud is a dedicated deployment, which matters for air-gapped or strictly segmented environments.
- Operator: The enterprise Kubernetes operator is offered as part of Qdrant Private Cloud.
- Commercial scope: Feature availability, support and uptime terms are set by the written agreement, not by the public tier table.
- Infrastructure: You still provide the underlying compute, storage and network that the clusters run on.
Ask Qdrant sales which operational features (zero-downtime upgrades, rebalancing, backups) are included in your specific Hybrid or Private Cloud agreement and who performs each one.
A single self-hosted node is the simplest self-managed setup. The open-source engine is free to run, and Qdrant's security documentation notes that a default self-deployed instance listens on all network interfaces with no authentication configured, so access controls must be set before anything else. Qdrant needs block storage with a POSIX-compatible file system, not NFS or S3, and SSD or NVMe drives are recommended.
- Cost model: The engine is free under Apache-2.0, while hardware, storage and operations are your costs.
- Access control: Admin and read-only API keys, TLS for REST and gRPC, and JWT-based per-collection permissions are available in the open-source engine.
- Auditing: JSON audit logging of authenticated API operations has been available since v1.17.0.
- Snapshots: Backups are handled through Qdrant snapshots, which you schedule, store and test yourself.
- No managed failover: A single node has no built-in replica to take over if it fails.
Confirm your backup restore procedure and recovery time with your own infrastructure team, since no managed disaster recovery exists on a single node.
Self-hosted distributed mode uses the Raft consensus protocol for cluster topology and collection structure, splits collections into shards across nodes and keeps extra copies through a replication factor. A replication factor of 2 doubles storage. Qdrant recommends at least three nodes for production so quorum survives a node failure, and a shard count that is a multiple of the node count.
- Consensus: Raft manages cluster topology and collection structure across nodes.
- Sharding and replication: You plan shard counts and replication factors, and each replica adds storage cost.
- Rebalancing: Shard movement and resharding are handled by your operators, not automated as in Qdrant Cloud.
- Upgrades: The community Helm chart does not include zero-downtime upgrades or automatic shard rebalancing, so rolling upgrades need your own runbook and testing.
- Enterprise operator: The operator with those capabilities is part of Qdrant Private Cloud, not the community chart.
Review the distributed deployment documentation and test node failure, rolling upgrade and snapshot restore in a non-production cluster before committing to a production design.
What you pay for in each model and what drives it up
Qdrant Cloud is a usage-billed service: clusters are charged hourly for vCPU, memory, storage, backup storage and any paid inference tokens, according to the Qdrant pricing page. The free single-node tier is positioned for testing and prototypes, and the Standard tier is usage-priced. Premium carries a minimum spend on top of usage, so a team that expects to stay small should check whether the minimum is higher than its expected monthly consumption. Costs rise with replica count, backup retention, and the size of the cluster needed to hold your vectors and payloads. Ask the vendor for a worked estimate that uses your vector count, dimensions, replication factor and backup schedule.
Self-hosting moves the bill to your own infrastructure. The one-time costs are planning, installation, network and security hardening, and the first load of data. The recurring costs are compute, block-level SSD or NVMe storage, backups, monitoring and staff time for upgrades and incident response. Qdrant's installation docs state that it cannot run on NFS or S3-style object storage, so storage prices must be quoted for block volumes. Replication is the cost multiplier to model: a replication factor of 2 doubles storage, and the distributed deployment docs recommend at least three nodes for quorum, so a production cluster needs more capacity than a single node holding the same data.
Hybrid Cloud and Private Cloud are priced through Qdrant sales, and the pricing page does not publish figures for them. DeployOpen does not publish prices either. Its work is fixed-scope, so a quote follows from a written scope that should list the Qdrant edition or deployment path, the nodes and storage to be provisioned, the security configuration (API keys, JWT access control, TLS and audit logging), the upgrade approach, backup and restore testing, and the support or retainer terms. Ask Qdrant for the Premium minimum spend and the Hybrid or Private Cloud terms in writing, then compare them with your own infrastructure and staff estimate on equal assumptions.
What your team runs in each model
This table sets out who performs each day-to-day operating task under Qdrant Cloud, Hybrid or Private Cloud, and self-hosted open-source Qdrant. Read each row as a question to put to Qdrant and to your own team before choosing a model, since managed responsibilities vary by contract and should be confirmed in writing.
| Operating task | Qdrant Cloud | Self-hosted Qdrant |
|---|---|---|
| Provisioning | Qdrant provisions managed clusters on AWS, Azure or GCP, billed hourly for vCPU, memory, storage and backups. Confirm the exact provisioning scope with Qdrant. | Your team provisions nodes, block storage with a POSIX file system, networking and the cluster itself. Qdrant does not run on NFS or S3. |
| Version upgrades | Qdrant documents easy version upgrades with zero downtime on highly available clusters. Confirm the upgrade windows and notice periods with Qdrant. | Your team plans, tests and applies each release, such as v1.19.2 published October 5, 2026. The community Helm chart lacks zero-downtime upgrades. |
| Scaling | Horizontal and vertical scaling up and down is documented as a managed capability. Confirm the cost and lead time of resizing with Qdrant. | Your team adds or removes nodes and sizes the cluster, using a shard count that is a multiple of the node count. |
| Shard rebalancing and resharding | Automatic shard rebalancing is documented as a managed feature. | Your team performs rebalancing and resharding by hand, and the community Helm chart does not automate it. |
| Backups and restore testing | Backups and disaster recovery are documented managed features. Ask Qdrant for restore objectives and how restore tests are run. | Your team configures snapshots, stores them off the cluster and runs restore tests on a schedule you define. |
| TLS and API key rotation | Qdrant manages the cluster endpoint. Confirm how certificates and API keys are rotated and who holds the keys. | Self-deployed instances listen on all interfaces with no authentication by default, so your team configures TLS, admin and read-only API keys, and rotates them. |
| Monitoring | Qdrant operates the managed service. Confirm which metrics, logs and alerts you can access and export. | Your team selects, deploys and maintains monitoring for node health, memory, disk and query latency. |
| Node failure handling and quorum | Highly available clusters are managed by Qdrant. Confirm failover behavior and the recovery commitments in your agreement. | Qdrant uses Raft for cluster topology. Qdrant recommends at least three nodes so quorum survives a node failure, and your team handles recovery. |
| Storage sizing | Storage is billed as part of the hourly resource model. Ask Qdrant how to size for your vectors, payloads and replication. | Your team sizes disks, accounting for the replication factor, which doubles storage at a factor of 2, and SSD or NVMe recommendations. |
| Audit log handling | Qdrant documents JSON audit logging of authenticated operations since v1.17.0. Confirm where logs are stored, how long they are kept and how you export them. | Your team enables audit logging, ships logs to your retention system and handles access reviews for the API keys and JWT permissions. |
How to move from self-hosted Qdrant to Qdrant Cloud and back
This sequence moves a collection from a self-hosted Qdrant engine into Qdrant Cloud, or back out, with a verified copy and a controlled client cutover at each end. The reader ends with a working target, validated data and a rollback path that does not depend on the license.
Confirm the current migration path with Qdrant
Before any data moves, the platform or database owner asks Qdrant for the current migration procedure, expected downtime and any data transfer charges for your region and cluster size. Qdrant's pricing FAQ states that an existing OSS deployment can be migrated to Qdrant Cloud, and the migration tool page is the starting reference. Record the answers in the change ticket. The step is done when the written answers name the tool or method, the cutover window and who pays for transfer.
Inventory collections, payloads and API keys
The engineering team lists every collection, its vector size and distance settings, payload indexes, quantization configuration and the clients that read or write it. It also lists the admin and read-only API keys and any JWT-based access rules in use on the self-hosted instance. Qdrant's security documentation covers these access controls, so the inventory shows what must be recreated on the target. The step is done when each collection has an owner, a client list and an access rule written down.
Create a snapshot of each collection
The operator creates a snapshot of each collection on the self-hosted cluster, following Qdrant's snapshots documentation. Snapshots capture the data needed to restore a collection elsewhere, so this is the artifact the transfer depends on. The team stores the files in a location that the target can read, and records file sizes and checksums. The step is done when every snapshot in the inventory has a stored copy and a recorded checksum, and the source is still serving traffic.
Provision and validate the Qdrant Cloud target
The team creates the Qdrant Cloud cluster in the tier that matches the workload, reviewing the Standard and Premium options against the uptime and identity needs documented on the pricing page. They restore a snapshot into a non-production cluster first, then run known queries and compare result counts, payload filters and recall against the source. Qdrant Cloud runs on AWS, Azure and GCP, so the region must match data residency rules. The step is done when test queries return matching results and the cluster's resource use is understood.
Recreate access controls on the target
The security team creates the Qdrant Cloud API keys and access rules that replace the self-hosted ones, granting each application only the collection permissions it needs. They check that TLS is enforced for every client path and that no endpoint is left open. Because self-hosted Qdrant ships without authentication by default, this step should not be skipped during a move. The step is done when a test client with the old key is rejected and a client with the new key reads and writes only its permitted collections.
Cut over clients in a controlled window
The application owners pause writes to the source collection, take a final snapshot of any changes made since the first copy, and restore it to the production cluster. They then change the endpoint and key in each client configuration, one service at a time, while the old cluster stays readable for rollback. Monitoring compares query latency and error rates against the baseline. The step is done when all clients point to Qdrant Cloud, error rates match the baseline, and the old endpoint has stopped receiving writes.
Run the reverse move on a defined trigger
If the team later returns to self-hosting, the same sequence runs in reverse: snapshot from the cloud cluster, transfer the files into a self-managed Qdrant instance, and validate it before any client changes. Because Qdrant is Apache-2.0 licensed, the exit path is not blocked by license terms, though data transfer and any cloud egress charges still apply. The operator should confirm with Qdrant which export options are supported for the cluster tier. The step is done when the self-hosted copy passes the same query checks and clients are re-pointed.
Questions buyers ask before choosing Qdrant Cloud or self-hosting
Is self-hosting Qdrant free?
The engine is free to self-host. Qdrant is licensed under Apache-2.0, and the open-source engine carries no license fee. The cost moves to everything around the software: the compute, memory and block storage you provision in your own cloud account or data center, the backups you run, the monitoring you set up, and the engineering time to operate it. These costs recur every month, while the initial build of the deployment is largely one-time. Qdrant Cloud bills hourly for vCPU, memory, storage, backup storage and paid inference tokens, so compare your own infrastructure bill and staff hours against that usage model, not the license line. Ask any provider for a written breakdown of what is included in each tier.
How much effort does a self-hosted Qdrant cluster take to run?
A production cluster is more than a single container. Qdrant's distributed deployment documentation recommends at least three nodes so quorum survives a node failure, and it uses Raft consensus for cluster topology and collection structure. Choose a shard count that is a multiple of the node count so data spreads evenly. The replication factor keeps extra copies, and a factor of 2 doubles storage. Rebalancing and resharding are manual tasks in a self-hosted cluster, while Qdrant Cloud documents automatic shard rebalancing. Plan for capacity reviews as the collection grows, and test node failure before you go live.
Can our team run self-hosted Qdrant without outside help?
Yes, if your team already runs stateful services well. Qdrant needs block-level storage with a POSIX-compatible file system, and it cannot run on NFS or S3-style object storage, so SSD or NVMe volumes are the expected choice. Production paths are the managed Qdrant Cloud, a community-supported Kubernetes Helm chart, or an enterprise Kubernetes operator that comes with Qdrant Private Cloud. The Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing. Skills you need include Kubernetes or VM operations, storage tuning, backup and restore testing, and upgrade planning. A team without those skills should price an outside engagement, scoped in writing, before committing.
Does self-hosted Qdrant need hardening before it holds production data?
Yes. The Qdrant security documentation states that self-deployed instances are not secure by default: they listen on all network interfaces and have no authentication configured. Before go-live, configure admin and read-only API keys, enable TLS for REST and gRPC, restrict network exposure, and decide whether you need JWT-based access control with per-collection read or write permissions. JSON audit logging of authenticated API operations is available in recent releases, so confirm the version you run supports it. Managed tiers handle parts of this for you, but you should still review what each tier configures on your behalf.
How long does migrating from self-hosted Qdrant to Qdrant Cloud take?
Qdrant's pricing FAQ states that an existing Qdrant OSS deployment can be migrated to Qdrant Cloud, and Qdrant publishes a migration tool and documentation for the process. No duration is published in the sources used here, so ask Qdrant for a written estimate based on your collection sizes, vector dimensions, payload volume and network path. Duration depends mainly on data volume, the bandwidth between your environment and the target region, and how much downtime your application can tolerate during cutover. Test the migration on a copy of a representative collection first, and confirm that search results match before you switch traffic.
What does Qdrant Premium add over Standard?
Premium is the tier with a minimum spend, and it adds SSO, private VPC links and a 99.9% uptime SLA. Standard is usage-priced, adds dedicated resources and high availability, and carries a 99.5% uptime SLA. The decision turns on three things: whether your identity team requires SSO for the cluster console, whether traffic must reach the cluster over private network paths rather than the public internet, and whether a 99.9% SLA matches your service commitments. Compare the minimum spend against your expected Standard usage before choosing. Confirm the exact SLA terms and credits in writing with Qdrant.
Do we need a consultant to produce compliance evidence for a Qdrant deployment?
Not necessarily, but someone must own the evidence. Qdrant does not issue certifications for your deployment, and the evidence an assessor expects depends on your framework and your environment. Typical evidence includes access control configuration, TLS settings, audit log retention, backup and restore test results, change records for upgrades, and network diagrams. Your internal compliance team can collect much of this if it knows where to look. A consultant is worth considering when controls are undocumented, when the cluster is new to your audit scope, or when you need the configuration reviewed before an external assessment. Any engagement should have written scope, deliverables and timelines agreed before work starts. Independent auditors and certification bodies, not consultants, issue the attestations.
Which deployment option fits a regulated team that needs data kept in its own network?
Hybrid Cloud and Private Cloud are the Qdrant options built for this question, and both are priced through Qdrant sales. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure with data staying in your network. Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment aimed at strict security, compliance and air-gapped needs. Self-hosting the open-source engine also keeps data in your network, but you take on the operations work. Ask each option for its written responsibility split, its upgrade model and the evidence it provides for your controls.
How DeployOpen scopes and runs self-hosted Qdrant
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Qdrant, that means helping a team decide where the vector database should run, then building and handing over the self-hosted cluster on the team's own infrastructure when that is the chosen path.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the Qdrant version, deployment path (single node, distributed cluster or Kubernetes) and the storage platform.
- We confirm which access controls, API keys, TLS and audit logging the team requires before any configuration begins.
- Scope records which corpus sizes, replication factor and node count are assumed, so the quote follows from explicit inputs.
How we build
- We install Qdrant on block storage with a POSIX-compatible file system, as the installation documentation requires, and document the storage choice.
- We enable authentication, TLS and per-collection access before the instance is reachable, since self-deployed Qdrant ships without authentication by default.
- For distributed mode, we configure a multi-node Raft cluster with shard counts and replication factors planned against the chosen node count.
- We test snapshot backup and restore, and we document the rebalancing and upgrade steps the team must run by hand.
How we hand over
- Handover includes configuration records, runbooks for upgrades, scaling and node replacement, and backup and restore procedures.
- We document the cost components that remain with the client, including compute, storage, backup and staff time for upgrades.
- We set out which managed features, such as zero-downtime upgrades and automatic shard rebalancing, the self-hosted design does not provide.
- Evidence for compliance readiness is prepared as documentation, while independent auditors and certification bodies issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Qdrant version upgrades, security testing of the API and access controls, and restore drills.
- Teams that later move from self-hosted Qdrant to Qdrant Cloud can ask for a scoped migration plan based on the documented OSS to Cloud path.
