When self-hosted Weaviate beats Weaviate Cloud, and when it does not
Choose Weaviate Cloud when your team wants Weaviate run as a managed service and does not have, or does not want to build, in-house cluster skills. Choose self-hosted Weaviate when embeddings and backups must stay inside your own cloud accounts, data center or air-gapped network, or when you already operate a Kubernetes platform that can host the Helm chart. Weaviate Cloud fits teams that want operations handled by the vendor and a published uptime tier to contract against: the pricing page lists Flex with a 99.5% uptime SLA and Premium with up to 99.95% and a 1-hour Sev 1 response, while the Free plan carries best-effort availability. Confirm the exact terms, regions and data handling in the written agreement, because the SLA text, not the marketing page, is what binds you.
The licensing split matters before you decide. The Weaviate core is BSD-3-Clause, but code in the repository's wl directory is covered by a separate Weaviate enterprise license, and enterprise features are enabled by a license key. Ask which features you need, such as the RBAC, replication or backup capabilities you plan to depend on, and confirm whether each one is in the open-source core or behind a key. Managed Weaviate Cloud removes the key-management question from your team, but it also means you cannot inspect or host the component yourself, so verify the feature list for your chosen plan against your requirements in writing.
Self-hosting is the stronger choice when residency or network rules decide the question, and it carries recurring work that a managed plan transfers to the vendor. Plan for the cost of the infrastructure, the people who patch, upgrade and back up the cluster, and the on-call rota for replication failures. Replication is disabled by default and set per collection with a replication factor, so a self-hosted cluster needs deliberate configuration that a managed service applies for you. A practical test: if you cannot name who restores a backup at 2 a.m. and who approves a Weaviate upgrade, Weaviate Cloud is probably the safer starting point.
Weaviate Cloud and self-hosted Weaviate side by side
This table sets Weaviate Cloud's published plans and usage rates against running open-source Weaviate yourself on Docker, Kubernetes or another host. Read each row as a question to answer for your own environment, since several cells depend on the plan you buy or a license key you hold. The main takeaway is that the managed service removes the operating work, while self-hosting keeps the data and the infrastructure choices in your hands.
| Factor | Weaviate Cloud | Self-hosted Weaviate |
|---|---|---|
| Published entry price | Free plan at $0 with best-effort availability; Flex starts at $45 per month pay-as-you-go (Weaviate pricing page) | No vendor subscription for the open-source core under BSD-3-Clause; you pay for hosts, storage, backup and staff time |
| Usage billing | Flex bills per million vector dimensions ($0.00465), per GiB of storage ($0.12) and per GiB of backup ($0.03036), varying by index type, compression and region | Usage is set by your own compute, disk and object storage contracts; confirm your cloud or data center rates |
| Uptime commitment | Flex carries a 99.5% uptime SLA; Premium on prepaid contracts lists up to 99.95% and a 1-hour Sev 1 response (confirm terms in the contract) | No vendor SLA; availability depends on the replication factor, hosting design and your on-call coverage |
| License boundary | Managed service runs the Weaviate open-source project wrapped in a managed service | Code outside the wl directory is BSD-3-Clause; code in wl requires a Weaviate enterprise license and a license key to enable those features |
| Authentication and RBAC | Access controls follow the managed plan; confirm which authentication methods and role management your plan exposes | API key and OIDC authentication are available; the user management API assigns custom roles and permissions through RBAC |
| Replication | Confirm the replication settings and consistency levels offered on your plan and region | Leaderless and disabled by default; enabled per collection with a replication factor and ONE, QUORUM or ALL consistency set at query time |
| Installation options | Managed Weaviate Cloud, with AWS and GCP marketplace deployments documented separately | Docker, Kubernetes, or other self-managed hosts in your own cloud, data center or air-gapped network |
| Data residency control | Data is stored in the regions the service offers; confirm available regions and data location terms before committing | You choose the location, network path and key management, which matters when regulators or customers set residency rules |
| Operating effort | Vendor handles upgrades and infrastructure within the plan; you still own schema design, data and access policy | You plan upgrades, scaling, backups, monitoring and access reviews, usually with your platform or DBA team |
Where your data sits and what compliance proof you need to produce
The deployment model decides who holds your vectors, who can reach the cluster and which records an assessor will ask for. Each card below covers one of those decisions, so the evidence you prepare follows from the model you choose rather than from the product brand.
Data location in vendor cloud
On Weaviate Cloud, your objects and vectors are stored in infrastructure the vendor operates, so the region and storage location are contract and configuration questions rather than something you control directly. Ask Weaviate which regions your plan can use, where backups are kept and where copies of your data may be processed. Confirm these answers in writing before you record them as residency evidence.
Data location in your own account
With self-hosted Weaviate on Docker or Kubernetes, the cluster, its persistent volumes and its backups sit in your cloud account or data center. You can show an assessor the exact host, network and storage locations, and you decide which backup target receives copies. The evidence shifts to your own access logs, storage encryption and backup configuration.
Who can reach the cluster
Access depends on who operates the platform. Vendor-managed clusters add the vendor's staff and subprocessors to the access picture, so ask how Weaviate limits and logs its own administrative access. Self-hosted clusters put that question back on your team, which means network policies, bastion access and admin accounts become the records you must produce.
Authentication options and anonymous access
Self-hosted Weaviate supports API key authentication and OIDC authentication, and it also offers anonymous access, which the documentation discourages outside development. Pick one of the authenticated modes for any environment that holds real data and record which mode is enabled in each cluster configuration. A reviewer will look for anonymous access in production first, so disable it outside development.
RBAC through the user management API
The user management API assigns custom roles and permissions, which lets you show least privilege per user or service account. Export the role definitions and the list of accounts bound to each role as evidence of access control. Check whether the managed plan you are considering exposes the same role model, because the access record you produce has to match the platform you actually run.
Evidence you must produce for each model
Vendor-managed deployments rely on the provider's certifications and reports, which you request and retain, while self-hosted deployments need your own configuration baselines, backup tests and access reviews. DeployOpen prepares controls and evidence for your assessment but does not issue audit reports, attestations or certifications, so independent auditors and certification bodies make those determinations. Confirm the vendor's certifications and subprocessor list directly with Weaviate before the assessment starts.
Which features depend on the enterprise license in self-hosting
Start with the license split, because it decides what a self-hosted team can run without paying Weaviate. Source code outside the repository's wl directory is BSD-3-Clause. Code inside wl is available only under a separate Weaviate enterprise license, and enterprise features are switched on by a license key. The open-source core covers the vector store, hybrid search, multi-tenancy and per-collection replication settings as described in the README. Before you commit to a design, map each requirement to one of three buckets: available in the BSD-3-Clause core, gated behind the enterprise license key, or only available in Weaviate Cloud at a given plan. Do not assume that a feature in the core on paper is covered by your current support arrangement, and do not assume that a Cloud plan includes a feature until Weaviate confirms it for that plan.
Map the specific controls your team needs. Replication is configured per collection with a replication factor, and consistency levels ONE, QUORUM and ALL are set at query time, so you can test these settings against your own collections. Backups, RBAC through the user management API, and OIDC authentication each need a check against the authentication docs and the current LICENSE file. For RBAC, confirm whether custom roles and permissions are available on the edition you will run, since the authentication docs describe the feature but the license boundary is what governs its use. Note that Cloud pricing bills backup storage separately, so the backup decision carries a cost in both models. Ask Weaviate, in writing, which of these features are included in the Free, Flex and Premium plans and which require an enterprise license key for self-hosting.
Turn the answers into a short decision record. List each required feature, its license bucket, the Cloud plan that includes it, and the named Weaviate contact who confirmed it. If a required feature needs an enterprise license, put that cost into your total cost of ownership and into the quote you request, because license terms are not something an implementation partner can settle for you. DeployOpen can help plan and test the self-hosted configuration within a written scope, but feature entitlements come from Weaviate's license terms. Re-check the LICENSE file and the Weaviate pricing page before signing, since both can change between releases.
Which hosting model fits which team situation
A product team that ships features but has no one dedicated to running infrastructure usually values predictable operations over control of the stack. Weaviate Cloud moves provisioning, upgrades and the underlying service into a managed plan, so the team's main ongoing job is schema design, ingestion and query tuning. Self-hosting shifts patching, backups, restore testing, certificate handling and monitoring onto whoever is on call, which is the work this team is least likely to have capacity for.
- Operational ownership: Managed plans leave upgrades and service availability with the provider, while self-hosting leaves them with your team.
- Published tiers: The Free plan is listed at $0 with best-effort availability, Flex starts at $45 per month pay-as-you-go with a 99.5% uptime SLA, and Premium starts at $400 per month on prepaid contracts with up to 99.95% uptime.
- Availability needs: If the product cannot tolerate best-effort availability, the Free plan does not fit production traffic.
- Required skills: Self-hosting needs someone who can run Docker or Kubernetes, configure replication and back up and restore data.
Before choosing, confirm the SLA terms, support response times and backup retention in the current Weaviate pricing terms, and ask what the team would own during an incident.
A regulated organization that must keep embeddings, source documents and derived data inside its own cloud accounts, data centers or private networks has a hard constraint that a managed service may not satisfy. Self-hosted Weaviate runs in that environment, and the team controls where objects, vectors and backups reside. The question is less whether a managed plan is secure and more whether the data location, subprocessor list and access paths meet the organization's residency and control requirements.
- Residency control: Self-hosting keeps vectors and backups in locations the organization selects and documents.
- Access controls: Self-hosted Weaviate supports API key authentication and OIDC, and its user management API assigns custom roles through RBAC.
- Enterprise features: Code inside the repository's
wldirectory is under a separate Weaviate enterprise license and enterprise features are enabled by a license key, so confirm which controls you need are included in the edition you license. - Evidence: Auditors will ask for configuration, access logs and backup test records, which your team must produce for a self-hosted deployment.
Verify with the data protection officer and the assessor which residency and access statements apply, and confirm the enterprise license scope with Weaviate before relying on any gated control.
A team that already operates a Kubernetes platform, with cluster tooling, monitoring, secret management and backup routines in place, can often run Weaviate as one more workload instead of a separate service. The Weaviate README lists Kubernetes as an installation option, and replication is configured per collection with a replication factor, so the platform team's existing practices for storage, node placement and failure handling apply. The main cost is the operating time your platform team already spends, plus whatever the vector workload adds to cluster capacity.
- Reuse of existing practice: Your current GitOps, monitoring and backup tooling can cover Weaviate if it fits your standards.
- Replication settings: Replication is leaderless, disabled by default and enabled per collection, so set replication factors deliberately rather than assuming they are on.
- Consistency choices: Tunable ONE, QUORUM and ALL consistency levels are set at query time, which affects latency and availability during node failures.
- Capacity drivers: Memory, storage and backup volume grow with the number of objects and vector dimensions, and compression changes the footprint.
Confirm the chart version, storage class requirements and backup target with your platform team, and estimate the on-call impact against the managed plan's cost before choosing.
A team that is still testing retrieval quality, or whose traffic rises and falls sharply, needs a cost model that tracks usage. Weaviate Cloud's Flex plan bills pay-as-you-go, and its published rates depend on vector dimensions, storage and backup, with rates that vary by index type, compression and region. A prototype on the Free plan carries best-effort availability, so it suits experiments rather than user-facing traffic. Self-hosting a prototype costs little in license fees because the core is BSD-3-Clause, but it adds setup and maintenance time that is easy to undercount.
- Flex cost drivers: Usage is billed from $0.00465 per million vector dimensions, $0.12 per GiB of storage and $0.03036 per GiB of backup, so dimension count and retained backups drive the bill.
- Index and compression choices: Index type, compression and region change the rates, so model costs with the settings you plan to ship.
- Idle cost: Prototype collections that sit unused still incur storage and backup charges on Flex.
- Migration path: Moving data later between a managed plan and self-hosting takes export, re-import and validation work.
Before committing, ask Weaviate to confirm current rates for your index type, compression and region, and run a sample dataset through both options to measure the real dimension and storage footprint.
What your team runs in each model
This table compares the recurring tasks a team carries under Weaviate Cloud and under self-hosted open-source Weaviate, and marks who covers each one. Read it as a staffing question: the rows that stay with your team are the ones to price into your own operating model, and the rows marked for confirmation are the ones to settle in writing with the vendor.
| Recurring task | Weaviate Cloud | Self-hosted Weaviate |
|---|---|---|
| Provisioning and sizing | Vendor provisions the managed service. You choose the plan and region and confirm capacity for your workload. | Your team or a partner provisions hosts, storage and networking with Docker or the Kubernetes Helm chart. |
| Upgrades | Vendor runs upgrades on the managed service. Confirm the notice period, maintenance windows and rollback path in writing. | Your team tracks releases such as v1.40.1 (October 13, 2026) and the 1.39 and 1.38 maintenance lines, tests them and schedules each rollout. |
| Replication per collection | Confirm which replication settings you can change and who sets the replication factor for each collection. | Your team enables replication per collection with a replication factor, since it is disabled by default. |
| Consistency levels ONE, QUORUM and ALL | Set at query time by your application. Confirm how the managed service handles failover during a node event. | Your application sets the level per query. Your team must test how each level behaves during node failure. |
| Backup setup and restore testing | Backups are billed per GiB on the pricing page. Confirm the backup schedule, retention and restore process and who runs restore tests. | Your team configures backup storage, schedules and restore drills. Restores you have not tested are not recovery plans. |
| Authentication and RBAC administration | Confirm which authentication methods and role management are exposed in Cloud and how user changes are audited. | Your team manages API key or OIDC settings and assigns custom roles through the user management API. |
| Monitoring and on-call | Vendor monitors the service. Confirm alert routing, what you are notified about and who you call for Sev 1 incidents. | Your team or partner builds the monitoring, alerting and on-call rota for the cluster and its dependencies. |
| Support response | Premium lists a 1-hour Sev 1 response on the pricing page. Confirm whether your plan carries it and the uptime SLA terms. | Support depends on your contracts with partners or your in-house team. There is no vendor SLA on self-hosted deployments. |
How to move data between Weaviate Cloud and self-hosted Weaviate
This sequence gives you a documented path for copying collections between Weaviate Cloud and a self-hosted instance, with a validated target and a rollback option before any client traffic moves. It is a planning frame, so confirm each step against the Weaviate documentation for the versions you run.
Inventory collections and their settings
List every collection, its vectorizer configuration, named vectors, properties, tenants and object counts, and record which application reads and writes each one. Your platform owner or engineer does this against the live cluster, and the output is a written inventory signed off by the application owners. Done means every collection has a documented schema and a named owner, so nothing is migrated by assumption.
Record replication and tenancy settings
For each collection, note whether replication is enabled, the replication factor, the consistency levels your clients use at query time, and whether multi-tenancy is in use with its tenant list. Replication is disabled by default and set per collection, so the target must be configured explicitly rather than inherited. Done means you have a settings sheet that the target configuration will be checked against.
Export or back up source data
Use the backup mechanism supported by the source and target versions to produce a complete copy of the data, and store it in storage the target can read. Confirm the exact export or restore method, its tooling and any storage requirements in the Weaviate documentation for your version, since no migration duration or cost is supplied here. Done means the backup completes and you have verified that the object counts recorded in step one match what the backup reports.
Validate the target with matching schema and authentication
Stand up the self-hosted target, apply the same collection schema, replication factor and tenancy settings, and configure authentication, whether API key or OIDC, with RBAC roles that mirror the source. Restore the data into this target in a non-production environment first. Done means the restored object counts match the source, a sample of queries returns the same results, and each role can only perform the actions it was assigned.
Test client compatibility before cutover
Point a staging copy of each client application at the validated target and run the read, write and hybrid search paths they use in production, including any RAG and reranking calls. Check client library versions against the target release. Done means every client passes its test cases and the owners of each application have signed off on the endpoint change.
Cut over clients in a controlled window
Freeze writes to the source or agree a cutoff, take a final incremental copy if your data changes during the window, and switch client endpoints and credentials to the self-hosted target. Your team runs the change, and the application owners watch error rates and latency. Done means clients are reading and writing against the target and the source has stopped receiving writes.
Keep a tested rollback path
Retain the Weaviate Cloud source cluster, its backups and the previous client configuration until the target has run stably for a period your organization sets. Write the rollback steps down, including how writes received during the new period would be reconciled, and rehearse them once. Done means someone who was not involved in the cutover can execute the rollback from the runbook, and you have recorded when the source can be decommissioned.
Questions buyers ask before choosing Weaviate Cloud or self-hosting
What drives the cost of Weaviate Cloud compared with self-hosting?
Weaviate Cloud bills you for the service, while self-hosting moves the bill to infrastructure and people. On the published Flex plan, usage is billed from $0.00465 per million vector dimensions, $0.12 per GiB of storage and $0.03036 per GiB of backup, and rates vary by index type, compression and region, so check the Weaviate pricing page for current figures. Self-hosted Weaviate has no license fee for the BSD-3-Clause core, but you pay for compute, storage, backup targets, monitoring, upgrades and the staff or partner hours to run them. Ask any quote to split one-time setup from recurring operations, to state which environments are included, and to name who carries on-call duties.
How much Kubernetes or database skill does self-hosting Weaviate require?
Running Weaviate yourself needs working knowledge of containers, storage, networking and backup, and more of it if you use Kubernetes. Docker Compose is the simplest documented route for a single host, while the Weaviate Helm chart on Kubernetes adds cluster operations such as persistent volumes, rolling upgrades and resource limits. Replication is disabled by default and is enabled per collection with a replication factor, so your team must understand consistency levels (ONE, QUORUM and ALL) and what happens during node failure. Confirm internally whether your engineers already operate stateful workloads of this kind, because that experience matters more than the product itself.
Can a small team run self-hosted Weaviate on its own?
A small team can run a single-node Weaviate instance on its own if it has someone comfortable with containers, backups and API key rotation. The workload becomes harder when you need multi-node replication, scheduled restores tested against real data, upgrades across minor releases and 24/7 response. Weaviate Cloud moves much of that work to the vendor, and its Premium plan describes a 1-hour Sev 1 response, but a self-hosted team must plan its own on-call coverage. If one or two people would carry the whole platform, consider a fixed-scope implementation with ongoing support so knowledge is documented and not held by one person.
How long does a self-hosted Weaviate rollout take?
The duration depends on the number of environments, the target platform, the identity model and how much data preparation the workload needs. A proof of concept on one host is much shorter than a multi-node production rollout that includes replication settings, backup and restore testing, authentication with OIDC or API keys, RBAC role design and monitoring. Work that is often underestimated includes agreeing on collection schemas, embedding pipelines and the procedure for rotating credentials. DeployOpen scopes these in writing before work starts, so ask for a fixed plan that lists each deliverable and what the client must provide, such as cluster access and identity provider settings.
Is data residency achievable with Weaviate Cloud?
Whether Weaviate Cloud meets your residency rule depends on the region options, contract terms and where backups and logs are kept, so confirm each item in writing with the vendor. Weaviate's pricing says rates vary by region, which shows that a region choice exists, but the supplied material does not establish which regions are available to you or how backups are located. If your rules require data to stay inside your own cloud accounts, data centers or an air-gapped network, self-hosting gives you direct control over placement. Ask the vendor for its data processing terms and for a written list of regions, backup locations and support access paths before you decide.
Does the enterprise license change the self-hosting decision?
It can, because enterprise features sit outside the BSD-3-Clause core. Weaviate's LICENSE file places code under the repository's wl directory under a separate enterprise license, and those features are enabled by a license key. Open-source Weaviate already includes API key and OIDC authentication, RBAC through the user management API, replication, multi-tenancy and quantization, so confirm which features your requirements need before assuming a paid tier is necessary. Ask the vendor to map each required feature to a license tier, to state how keys are issued and renewed, and to explain what happens to a running deployment if a key lapses.
A decision checklist for Weaviate hosting
Settle data residency before anything else, because it decides whether Weaviate Cloud is even an option. Write down which regions, accounts and networks may hold vector data, the embeddings derived from it, and the backups of both. Then check whether the managed plan's regions and data handling meet that requirement, using Weaviate's own pricing and documentation as the starting point and confirming the details in writing with the vendor. If residency is strict, self-hosting on your own cloud account or data center moves that decision inside your boundary, and the architecture comparison later in this page shows what that move costs you in operating work.
Next, list the enterprise features you actually need. Weaviate's open-source core is BSD-3-Clause, but code in the repository's wl directory is under a separate enterprise license and is enabled by a license key. Ask which of your controls depend on that boundary, such as advanced access features or support terms, and confirm the current licensing position with Weaviate before you design around it. Then settle expected scale for replication and backups: how many replicas per collection, which consistency level your queries need, and how often you must restore. Those answers drive the Flex or Premium comparison and the self-hosted replication settings, so record them with numbers from your own workload tests, not from assumptions.
Finally, be honest about who will run the cluster and how changes get approved. Name the people who will handle upgrades, backups, restore tests, API key rotation and OIDC or RBAC configuration, and confirm they have time for it. Also check your internal change control: if every production change needs a ticket, a window and a rollback plan, a managed service may shorten that path, while a self-hosted cluster needs those steps written into your own runbooks. If the answers to residency and enterprise features are both clear, the remaining decisions usually come down to platform capacity and the change process you already run.
How DeployOpen scopes and supports self-hosted Weaviate
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so Weaviate can run in your cloud account, data center or air-gapped network. Engagements start with a written, fixed scope that defines how the self-hosted option would be run for your team.
How we scope
- We confirm which Weaviate deployment path your workload needs before any build work starts.
- The written scope names the environment, the collections, replication settings and backup targets in scope.
- Scope and deliverables are agreed in writing, and a quote follows from that scope rather than a list price.
How we build
- We install and configure self-hosted Weaviate on Docker or Kubernetes in your environment, per the agreed scope.
- We set up API key or OIDC authentication and RBAC roles, then test access for each team that will use the cluster.
- We test replication, consistency settings and backup restores against the requirements you agreed in writing.
How we hand over
- We document the deployment, configuration, upgrade steps and backup and restore procedures for your operators.
- We deliver the written runbook, access model and evidence of restore tests so your team can operate the system.
- We walk your platform and security staff through the handover so ownership of each component is clear.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning covers Weaviate release changes, checked against your agreed configuration and backup plan.
- Ask for the retainer scope in writing, including who responds to incidents and which environments are covered.
