Is self-hosted Wazuh cheaper than QRadar on-premises cost?
Wazuh carries no license fee, so the comparison turns on what you pay to run it. Wazuh is free, open-source software distributed under the GNU General Public License version 2, so the subscription line that QRadar on premises brings, whether it is priced on events per second, flows per minute or Managed Virtual Servers, has no direct counterpart. What remains is infrastructure, storage, staff time, skills and any outside support you buy. Before you compare totals, pull your current QRadar renewal and your last two years of event volume, then ask your team to model the same events per second on Wazuh indexer, server and dashboard nodes. Confirm the licensing unit and renewal terms in your IBM agreement, because those define the baseline you are replacing.
Self-hosting tends to cost more in places that do not appear on a license invoice. Your engineers will install, tune, patch and upgrade four components: the Wazuh indexer, server, dashboard and agents. Wazuh's current line is 4.14, and its 4.14 patch releases arrived roughly every one to two months in 2026, so budget recurring time for upgrades and testing. Storage growth is the largest variable: the indexer keeps alerts and raw data on hardware you own, so retention periods, replica counts and the size of the server cluster drive hardware and disk costs up year after year. Skills matter as well. Decoder and rule writing, and the work to bring QRadar offenses and log sources across, need people who know Wazuh well or a partner who does. Ask any outside party for a fixed-scope quote that names each of these items.
Self-hosting tends to cost less where the subscription drove the spend. You avoid a recurring license charge and any per-event fee, so cost scales with the hardware, storage and people you choose rather than with a vendor's metering. Wazuh's agents also cover endpoints, file integrity and vulnerability detection in one tool, which can reduce the number of separate products you license. Keep in mind that hardware refresh is still a recurring cost you own, and that an appliance renewal may be replaced by a server or virtual machine budget rather than eliminated. A practical check is to write down, per year, the QRadar line items you can retire, the Wazuh infrastructure and staffing you will add, and the retention you need for compliance, then compare the two totals at the same event rate.
Cost components on each side and what recurs
This table lines up each cost component of an on-premises QRadar deployment against the same component in a self-hosted Wazuh and OpenSearch stack handling the same event rate. Read the one-time and recurring columns first, because most of the difference over a multi-year term comes from recurring license and support lines on the QRadar side and from staff time and hardware refresh on the open-source side.
| Cost component | Commercial side (QRadar) | Self-hosted side (Wazuh and OpenSearch) | One-time or recurring |
|---|---|---|---|
| License or subscription | QRadar license tier sized by events per second (EPS), flows per minute or Managed Virtual Servers, renewed by term | No license fee for Wazuh (GPLv2). OpenSearch is Apache 2.0 with no paid edition, so the software line is zero | Recurring on QRadar; none on the open-source stack |
| Appliance or server hardware | QRadar appliances or certified hardware, refreshed when capacity or hardware support ends | Servers or VMs for the Wazuh indexer, server and dashboard, sized by event rate and retention | One-time purchase, then refresh every hardware cycle on both sides |
| Storage | Event and flow storage sized by the QRadar retention plan and appliance capacity | OpenSearch indices on your own disks or object storage, sized by daily volume multiplied by retention days and replicas | Recurring as data grows; storage refresh is a one-time purchase each cycle |
| Network | Collector and flow sensor links to the QRadar console and event processors | Agent and syslog traffic to the Wazuh server, plus node-to-node traffic in an indexer cluster | One-time design, recurring bandwidth on existing circuits |
| Implementation and migration | Vendor or partner services for deployment, DSM and rule rebuild, and data export | Your team or an outside implementer for installation, decoders, rules, agent rollout and export of QRadar history | One-time; confirm scope and rates in a written quote |
| Support and maintenance | IBM support renewal on the license, typically billed annually | Optional subscription from Wazuh or outside support providers, plus any retainer you contract | Recurring if you buy support; optional on the open-source side |
| Upgrades and patching | Included in the support renewal for supported releases; upgrades scheduled by IBM and your team | Wazuh 4.14 patch releases and OpenSearch minor releases roughly every eight weeks, applied by your team or a retainer | Recurring staff effort on the open-source side |
| Internal skills and staff time | Analysts and administrators trained on QRadar AQL, offenses and DSMs | Engineers who run Linux, OpenSearch clusters, Wazuh rules and decoders, and agent fleets | Recurring; the largest line to size for a small team |
What moves the cost comparison most
QRadar and Wazuh price the same workload in very different ways, so the comparison turns on a handful of sizing inputs. Settle these before requesting a quote or costing hardware, because each one changes the licence, storage or staffing line.
Sustained event rate and licensing unit
QRadar on premises is licensed by events per second (EPS), flows per minute (FPM) or Managed Virtual Servers, depending on the agreement in place. Measure the sustained rate over a full business cycle, not a quiet week or a peak, and confirm with IBM which unit your contract uses. Wazuh has no license fee, so this figure drives indexer sizing and hardware instead of a renewal line.
Retention period and storage growth
Retention multiplies the cost of every event you keep. Decide how long searchable data must stay online and how long archives must be kept, since those are often different periods. In Wazuh, the indexer disk requirement grows with retention, so ask your team to model storage per day of retained data before buying hardware.
Endpoints with agents
Each endpoint that runs a Wazuh agent adds telemetry, and the agent count affects server load and alert volume. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so count endpoints by operating system and note which devices can only be covered by syslog. Devices that cannot run an agent, such as firewalls, are collected through syslog and periodic API probing.
Availability and clustering
A production SIEM needs a design for failure, not only capacity. The Wazuh server can run as a cluster for horizontal scaling, and the indexer needs its own redundancy plan. Each extra node adds hardware, licences for the operating system if applicable, and time to operate, so cost the high-availability design the way you would cost the QRadar appliance pair it replaces.
Compliance reporting scope
The Wazuh dashboard ships prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. Reports from these views support evidence gathering, but they do not make an organization compliant or replace an assessor. Count the frameworks you must report against, because each one adds rule tuning and evidence work your team owns, and ask whether your QRadar reports currently rely on paid content packs.
Air-gapped operation and team skills
Air-gapped sites need the offline installation path and an offline vulnerability repository instead of the online threat intelligence feed, which adds staff time to keep that data current. Your existing skills matter just as much: a team that already runs Elasticsearch-style clusters or Linux fleets will carry less training cost than one that depends on QRadar's packaged content and vendor support.
How to build the comparison with your own numbers
This sequence turns QRadar's contract and appliance terms into a like-for-like estimate against self-hosted Wazuh and OpenSearch at your measured event rate and retention. The output is a cost model you can defend in a renewal discussion or a written quote request.
Pull current QRadar license and support terms
Ask your IBM account team or reseller for the current license metric in your agreement, whether that is events per second, flows per minute or Managed Virtual Servers, and the licensed capacity for each. Record the renewal date, the subscription or support end date for every appliance, and any price step-ups written into the contract. Confirm in writing whether on-premises QRadar support follows the same terms as before the SaaS sale. You are done when every line item of the current spend, with its end date, sits in one table signed off by procurement.
Measure sustained event rate and retention need
Using the QRadar console or your SIEM exports, record events per second as a sustained average over at least one full business cycle, plus peak bursts, and separate the figure for log events from any flow volume. Note the retention your compliance and incident response obligations require, in days or months, for hot and archived data. Include a sample of the largest log sources so later decoder work is realistic. You are done when you have one sustained rate, one peak rate, and a retention period per data class, each with the date range it came from.
Size Wazuh and OpenSearch for the same load
Map the measured rate onto the Wazuh deployment options your team can operate, such as the step-by-step installation, Docker, Kubernetes or Ansible, and decide whether the server runs as a single node or a cluster. Size the Wazuh indexer, server and dashboard separately, since the indexer stores alerts and carries most of the search cost. Confirm current hardware and resource guidance in the Wazuh documentation for your rate, and test with a representative sample before committing. You are done when you have a node count and resource profile for each component, with a load test result that matches your sustained rate.
Price storage and hardware for the retention window
Multiply your daily indexed volume by the retention period to get raw storage, then add replicas, snapshot space and headroom for growth. Price the hardware or cloud instances for each tier, and compare them with the QRadar appliance refresh quotes you already hold, including any storage expansion. Remember that hardware cost is partly one-time and partly recurring through power, data center space, backup and replacement cycles. You are done when a storage and compute table covers each retention tier and shows both one-time and annual costs.
Estimate staff hours for content and upgrades
List the detection content you will rebuild, the log sources needing decoders or agents, and the dashboards and compliance views you rely on today. Estimate hours for each category based on your own team's records from recent tuning work. Add recurring hours for upgrades: Wazuh 4.14 patch releases shipped roughly every one to two months in 2026, and each one needs testing and a change window. Include on-call rotation time for the platform itself, since self-hosting moves operational responsibility to your team. You are done when staff time appears as a separate line with named roles, hours per month and whether it is one-time or recurring.
Decide on outside support and its scope
Compare the hours you cannot cover internally against the cost of a fixed-scope engagement or an ongoing retainer, and decide which work sits with your team. Typical outside work includes initial build and hardening, migration of content, upgrade runs and continuous testing. Use this step to decide whether support is needed at launch, during migration only, or as a standing retainer. You are done when each activity is labeled as internal, external or shared, with the reason written beside it.
Request written quotes with defined scope
Send a written scope listing your event rate, retention, log sources, compliance views and integrations, and ask each provider to quote against that scope. Ask for fixed deliverables, acceptance criteria, what is excluded, how upgrades and patches are priced, and whether any recurring fee changes with volume. Ask IBM to confirm any renewal discount and support terms in writing. You are done when every quote is comparable line by line against your model, and the open questions are recorded before a decision is made.
Which costs are one-time and which recur every year
The main difference is that QRadar costs are mostly recurring and Wazuh costs are mostly one-time or staffing. On the QRadar side, the recurring line items are the subscription or support renewal tied to your licensing model (events per second, flows, or Managed Virtual Servers), plus the appliance refresh cycle and any hardware maintenance on the appliances you already run. Each renewal resets the clock, so the figure to pin down first is the on-premises renewal quote for your current event rate. Ask IBM for the license metric, the term, what the renewal includes, and whether the price changes at the next term. The Palo Alto Networks sale of QRadar SaaS assets, announced in 2024, offered eligible SaaS customers a migration to Cortex XSIAM, but IBM continues to provide features and support to on-premises customers. Unless your environment is a SaaS tenant, the on-premises renewal remains the baseline you should compare against.
On the Wazuh side, the one-time costs are the initial build: sizing and procuring indexer, server and dashboard hardware, deploying agents, mapping log sources and decoders, rebuilding offense rules as Wazuh rules, and any migration of historical data. These are the costs most likely to sit in a project budget and not in an operating budget. The recurring costs are storage growth, which scales with retention and event volume, hardware refresh, and staff time for patching, upgrades and detection content. Wazuh's 4.14 line received patch releases roughly every one to two months in 2026, so budget for regular upgrade work. Staff time is the largest variable, and it is the one QRadar's support contract partly covers. Decide now whether that support gap will be filled by in-house engineers or by an outside support retainer, and get that retainer priced as a separate recurring line.
Build a five-year comparison that places each one-time item in year one and each recurring item in every year, then compare totals under the same event rate and retention period. Include storage for the retention you actually need for audits, because storage growth is often the cost that surprises teams after the first year. Ask any outside party for a fixed-scope quote with the work, deliverables and assumptions written out, so that the one-time build and the recurring support are priced separately. DeployOpen prepares these estimates from a written scope, and the figures should come from your own event rates and infrastructure rather than from published averages.
Questions buyers ask about SIEM cost and effort
How much effort does a self-hosted Wazuh deployment need, and can our team do it alone?
A small team with Linux administration, networking and some security operations experience can usually run Wazuh, but the effort depends on the size of the estate and the skills already present. Wazuh has four components: the Wazuh indexer, the Wazuh server, the Wazuh dashboard and agents on endpoints. Wazuh documents several installation paths, including an all-in-one install, a prebuilt OVA, Docker, Kubernetes, Ansible and Puppet, so the first build is rarely the hard part. The harder work is sizing the indexer and storage, writing decoders and rules for your log sources, and tuning alerts. Ask yourself whether you have people who can own those tasks every week, not only during the install.
What drives staff time in a self-hosted SIEM?
Staff time is driven less by the software and more by the work around it. The main drivers are the number and variety of log sources, how many custom decoders and detection rules you write, how much alert triage your analysts do, and how often you patch and upgrade. Compliance reporting also adds time when auditors ask for evidence. Vulnerability detection in Wazuh correlates software inventory from agents with vulnerability data from the Wazuh CTI platform or an offline repository, which reduces manual work but still needs someone to review findings. When you compare with QRadar, count the hours your team spends on QRadar content today, because that effort usually moves to Wazuh rather than disappearing.
Do we need outside support to run Wazuh and OpenSearch?
Outside support is optional, but it is a cost line you should plan for. Wazuh is free under GPLv2, and OpenSearch is licensed under Apache 2.0 with no paid edition described in its FAQ. The software itself carries no license fee, so any support you buy is a service contract. Wazuh also offers a Cloud product, which is a different cost model you should evaluate separately. Teams commonly weigh three options: staff who handle everything, a vendor support contract for the platform, or an implementation partner for the initial build and later retainers. Ask each option what it covers, who answers at night, and what happens when a critical fix is needed.
How long does a migration from QRadar take, and what does it depend on?
The duration depends on your log sources, the number of QRadar custom rules and building blocks, how much history you must keep, and how many teams consume the dashboards. No single timeline applies to every estate, so ask for a timeline based on your inventory. The steps that usually take the longest are mapping each QRadar log source to a Wazuh agent or decoder, rebuilding offense rules as Wazuh rules, and exporting or archiving history. Running both platforms in parallel for a period is common, because it lets analysts validate detections before the QRadar appliances are retired. Your existing QRadar rule and event counts are the best inputs for an accurate estimate.
How do upgrades recur, and what should we budget for them?
Upgrades recur on the vendor's release cadence, and the cost is the staff and test time to apply them safely. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months, according to its release notes. OpenSearch targets a new minor version about every eight weeks, and each version stays in maintenance for a set period, with 3.9.0 released on September 29, 2026. Plan a regular patch window, a test environment that mirrors production, and a backup before each change. Ask any partner how upgrades, testing and rollback are priced under a retainer.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists the log sources in scope, the number of detection rules to rebuild, the target architecture with sizing assumptions, and the deliverables for each phase. The quote should separate one-time work, such as design, installation, migration and documentation, from recurring work, such as support, upgrades and continuous testing. Ask who does the work, what the client must provide, how acceptance is tested, and what evidence is delivered for compliance reviews. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so a quote follows from that written scope. Compare quotes on the same inventory, not on headline day rates.
Where self-hosting costs more and how to plan for it
The largest cost in a self-hosted Wazuh deployment is usually the people who run it, not the software. Wazuh is free under the GNU General Public License version 2, but someone on your team must operate the Wazuh indexer, the Wazuh server and the dashboard, tune decoders and rules, and manage agent upgrades. Before you compare numbers with QRadar, confirm how many engineers you can staff for this work, which of them already know OpenSearch-style index management, and what your current QRadar administrators would need in training. Each of those is a line item that a license quote does not show.
Storage grows with retention, and retention is usually set by compliance rather than by engineering preference. Alerts and archived events stored in the Wazuh indexer consume disk for as long as you keep them, so every extra month of retention is a recurring cost that scales with your event rate. Ask your compliance lead which log sources must be kept and for how long, then size storage, snapshots and backup copies from that answer. Plan for clustering as well: the Wazuh server can run as a cluster for horizontal scaling, and a highly available indexer and server design adds nodes, load balancers and maintenance windows that a single QRadar appliance pair did not require. Ask your implementation partner to price these as separate, written components.
Compliance evidence is the third cost, and it is often underestimated. Wazuh's dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, but those views do not replace the evidence your auditor will request, such as retained logs, change records for rules and access reviews for the dashboard. Someone must collect that evidence and keep it current. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so budget for their fees separately and confirm their evidence expectations before the cutover.
How DeployOpen scopes a fixed-price implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure. For a QRadar cost comparison and a Wazuh deployment, we start by agreeing on the event rate, log sources and retention you actually need, so the cost model and the build plan rest on the same numbers.
How we scope
- We record your current QRadar license basis, EPS or FPM or Managed Virtual Server terms, and support end dates from your own contract.
- We inventory log sources and agent candidates, including which endpoints need Wazuh agents and which devices need syslog collection.
- We agree retention periods, storage locations and sizing assumptions, then document them in the written scope before any work starts.
How we build
- We deploy the Wazuh indexer, server, dashboard and agents in your environment, using the installation method your team chooses.
- We size the OpenSearch-backed storage against your measured event rate and retention, and record the hardware and storage cost lines.
- We configure authentication, TLS and role-based access, then test detections and compliance dashboards against sample events.
How we hand over
- We document architecture, sizing, parts list, configuration and runbooks so your staff can operate and scale the platform.
- We provide a side-by-side cost sheet that maps each QRadar line item to the Wazuh and infrastructure cost that replaces it.
- We run knowledge transfer sessions and hand over the platform with a written record of what was built and tested.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer, which covers patching the Wazuh release line.
- Confirm with us in the quote which items fall outside the written scope, such as staff training or third-party licensing.
