Understanding the Wazuh DB Architecture

Wazuh is made up of several specialized services that work together to collect logs, analyze security events, manage agents, and generate alerts.

Among these components, Wazuh DB is one of the most important but least understood.

Although administrators regularly interact with the Wazuh Manager, Dashboard, Indexer, and Agents, the internal database service quietly handles much of the platform’s day-to-day state management behind the scenes.

Unlike traditional relational databases such as MySQL or PostgreSQL, Wazuh DB is not designed for complex SQL queries, business reporting, or long-term analytics.

Instead, it is an embedded database service that focuses on rapidly storing and retrieving operational information needed by the Wazuh Manager and its agents.

This lightweight architecture allows Wazuh to process thousands of endpoint updates efficiently without introducing the overhead of a full database server.

As Wazuh deployments grow from a handful of endpoints to thousands or even tens of thousands of monitored systems, understanding how Wazuh DB works becomes increasingly important.

Performance bottlenecks, synchronization delays, excessive disk usage, and agent communication issues often trace back to the database layer.

Knowing how the architecture operates makes troubleshooting significantly easier and helps administrators build more scalable environments.

In this guide, you’ll learn:

What Wazuh DB is and why it exists
How it differs from traditional SQL databases
The internal architecture and major components
How data flows through the service
How SQLite powers the storage layer
Best practices for performance, scalability, and troubleshooting

Throughout the article, you’ll also see how Wazuh DB interacts with other platform components such as the Wazuh Manager, agents, File Integrity Monitoring (FIM), Vulnerability Detection, and cluster services.

Related Guide:

What Is Wazuh DB?

Definition of Wazuh DB

Wazuh DB (wazuh-db) is an internal daemon that provides a lightweight database service for the Wazuh platform.

It manages operational data required by the Wazuh Manager and its modules, acting as a high-performance storage layer for agent-related information.

Rather than serving as a general-purpose database, Wazuh DB is optimized specifically for security monitoring workloads.

It stores and retrieves information that changes frequently, allowing the Manager to access endpoint state quickly without repeatedly parsing configuration files or scanning the filesystem.

The service runs locally on the Wazuh Manager and communicates with other Wazuh components through Unix domain sockets, enabling low-latency data exchange.

Purpose Within the Wazuh Manager

Within the Wazuh Manager, Wazuh DB acts as the central repository for operational endpoint information.

Several Wazuh modules continuously read from and write to the database instead of maintaining separate storage mechanisms.

Examples include:

File Integrity Monitoring (FIM)
Syscollector inventory
Vulnerability Detection
Rootcheck
Agent metadata
Synchronization information
Internal module state

This centralized approach reduces duplication while allowing multiple services to share the same up-to-date information.

Lightweight Embedded Database Service

One of the biggest advantages of Wazuh DB is that it does not require installing or administering a dedicated database server.

Unlike enterprise SQL platforms, Wazuh DB:

Starts automatically with the Manager
Requires no separate authentication
Uses minimal memory
Has very low CPU overhead
Stores data locally
Is optimized for fast read/write operations

This design greatly simplifies deployment while maintaining excellent performance for security monitoring workloads.

How It Manages Agent-Related Data

Every Wazuh agent continuously sends information back to the Manager.

Examples include:

File inventory
Installed software
Hardware inventory
Security configuration assessments
File integrity events
Synchronization metadata
Internal status updates

Instead of writing all this information directly into flat files, Wazuh DB stores structured records that can be updated efficiently.

For example, when Syscollector reports installed software from an endpoint, Wazuh DB updates only the changed records rather than rewriting an entire inventory file. Likewise, File Integrity Monitoring updates only modified file entries instead of rescanning complete datasets.

This incremental update model significantly improves performance as environments grow.

Relationship with Other Wazuh Components

Wazuh DB is one layer within the larger Wazuh architecture.

A simplified interaction flow looks like this:

Wazuh Agent
      │
      ▼
Wazuh Manager
      │
      ▼
   Wazuh DB
      │
      ├── File Integrity Monitoring
      ├── Syscollector
      ├── Vulnerability Detection
      ├── Rootcheck
      └── Other internal modules
      │
      ▼
Wazuh Indexer
      │
      ▼
Dashboard

It is important to distinguish the roles of these components:

Wazuh DB stores operational and state information.
Wazuh Indexer stores searchable security events and alerts.
Wazuh Dashboard provides visualization.
Wazuh Manager performs analysis, decoding, and rule evaluation.

Many new administrators mistakenly assume Wazuh DB stores all security alerts.

In reality, alerts are indexed in the Wazuh Indexer, while Wazuh DB primarily supports internal platform operations.

Related Guide: How to Build a Wazuh Indexer Cluster

Why Wazuh DB Exists

Limitations of Flat Files

Earlier generations of host-based intrusion detection systems relied heavily on flat files to store endpoint state information.

While this approach works well for small deployments, it quickly becomes inefficient as environments expand.

Flat files present several challenges:

Slow lookups
Expensive updates
Difficult synchronization
Increased parsing overhead
Poor scalability
Higher risk of corruption during concurrent writes

As organizations begin monitoring thousands of endpoints, repeatedly reading and rewriting large files creates unnecessary CPU and disk activity.

Faster Data Retrieval

Databases are optimized for retrieving specific records without scanning entire files.

Instead of loading complete inventories into memory, Wazuh DB can quickly access only the information requested by a module.

This dramatically reduces latency for operations such as:

Retrieving agent metadata
Looking up monitored files
Updating software inventories
Synchronizing File Integrity Monitoring data
Reading vulnerability information

SQLite’s indexing capabilities make these lookups significantly faster than equivalent flat-file operations.

Efficient Agent State Management

Modern security platforms constantly update endpoint state.

Agents regularly report:

New software installations
Deleted files
Registry modifications
Hardware changes
Network interface updates
Security configuration assessments

Wazuh DB stores only the necessary changes, allowing modules to maintain accurate endpoint state without repeatedly processing unchanged information.

This approach becomes increasingly valuable when managing thousands of agents that send continuous updates.

Improved Scalability

Scalability is one of the primary reasons Wazuh introduced its database layer.

As deployment size increases, the Manager must efficiently coordinate:

Thousands of agents
Millions of monitored files
Continuous inventory updates
Scheduled scans
Synchronization tasks
Internal module communication

A lightweight embedded database provides substantially better performance than repeatedly processing large collections of text files.

The official Wazuh architecture recommends scaling manager components appropriately as endpoint counts increase.

Related Guide:

Reduced Disk I/O

One often-overlooked advantage of Wazuh DB is its ability to reduce disk activity.

Instead of rewriting large files after every update, SQLite modifies only the affected database pages.

Benefits include:

Lower disk utilization
Faster writes
Reduced SSD wear
Improved responsiveness
Better performance under heavy workloads

These efficiencies become especially important in large Security Operations Centers (SOCs) where endpoint inventories change continuously.

Better Synchronization Between Components

Many Wazuh modules rely on the same endpoint information.

Without a centralized database, each module would need to maintain separate copies of agent state, increasing both storage requirements and synchronization complexity.

Wazuh DB acts as the shared source of truth, allowing components such as Syscollector, FIM, Vulnerability Detection, and Rootcheck to access consistent data while minimizing redundant processing.

This architectural pattern aligns with widely accepted distributed systems principles that emphasize shared state management to reduce duplication and improve consistency.

Wazuh DB Architecture Overview

High-Level Architecture

At a high level, Wazuh DB sits between the Wazuh Manager and several internal modules, acting as the platform’s operational data layer.

          Wazuh Agents
                │
                ▼
         Wazuh Manager
                │
      Local Socket Requests
                │
                ▼
            Wazuh DB
                │
      SQLite Database Files
                │
      ┌─────────┼─────────┐
      ▼         ▼         ▼
   Syscollector FIM  Vulnerability Detection
      │         │         │
      └─────────┴─────────┘
                │
                ▼
         Wazuh Indexer
                │
                ▼
          Wazuh Dashboard

This separation allows detection logic, state storage, and alert indexing to operate independently while exchanging data efficiently.

Core Design Principles

The Wazuh DB architecture is built around several key design goals:

Lightweight resource usage
Fast local communication
Efficient state storage
Concurrent access by multiple modules
Minimal administrative overhead
High scalability
Reliable synchronization

These principles help Wazuh remain performant even in large enterprise deployments.

Local Socket Communication

Rather than exposing a network database service, Wazuh DB communicates internally using Unix domain sockets.

This provides several advantages:

Faster than TCP/IP communication on the same host
Lower latency
Reduced protocol overhead
Improved security because the service is not externally exposed
Efficient inter-process communication between Wazuh daemons

This architecture reflects a common design pattern for high-performance local services in Linux environments.

Database Storage Model

Wazuh DB stores structured operational data in multiple SQLite databases rather than one large monolithic database.

Different datasets are organized separately to improve maintainability and performance.

Examples include:

Agent information
File Integrity Monitoring metadata
Software inventory
Hardware inventory
Package information
Synchronization state
Internal module data

This separation helps reduce contention and allows modules to operate more efficiently on their respective datasets.

SQLite Backend

At its core, Wazuh DB uses SQLite, a mature embedded relational database engine known for its reliability, portability, and minimal resource requirements.

SQLite is widely deployed in production environments ranging from embedded systems to browsers and mobile operating systems.

The SQLite project notes that the database engine is extensively tested, with billions of deployments worldwide, making it a dependable choice for embedded applications.

Using SQLite provides several advantages:

No standalone database server
ACID-compliant transactions
Reliable crash recovery
Fast indexed lookups
Small memory footprint
Minimal administrative overhead

This makes SQLite particularly well suited for Wazuh’s operational data layer, where low latency and reliability are more important than complex analytical queries.

Event-Driven Operations

Wazuh DB follows an event-driven model.

Instead of continuously polling for changes, modules interact with the database when new events occur.

For example:

An agent sends updated software inventory.
The Wazuh Manager receives the event.
Syscollector processes the data.
Wazuh DB updates the relevant SQLite records.
Other modules can immediately access the updated information.

This architecture minimizes unnecessary processing and keeps operational data synchronized across the platform.

The Wazuh engineering team designed this modular approach to reduce coupling between components while improving scalability and maintainability as deployments grow.

Core Components of Wazuh DB

Understanding Wazuh DB becomes much easier when you break it down into its core components.

Rather than being a single database file, Wazuh DB consists of several parts that work together to receive requests, process data, store information, and return results to other Wazuh services.

The primary components include:

The wazuh-db daemon
Multiple SQLite databases
A Unix domain socket for communication
An internal query engine

Each component has a specific role in ensuring the Wazuh Manager can efficiently manage thousands of monitored endpoints.

Wazuh DB Daemon (wazuh-db)

The wazuh-db daemon is the service responsible for managing all database operations within the Wazuh Manager.

It acts as an intermediary between Wazuh modules and the underlying SQLite databases.

Instead of allowing every module to access database files directly, all requests are routed through this daemon.

This centralized design improves consistency, prevents database corruption, and allows multiple processes to safely access the same data.

Purpose

The primary purpose of the daemon is to provide a lightweight database service for the Wazuh platform.

Its responsibilities include:

Processing database requests
Managing SQLite connections
Handling concurrent operations
Updating agent information
Returning query results
Maintaining database integrity

By acting as a dedicated database layer, Wazuh DB separates storage logic from detection and analysis logic.

Startup Process

When the Wazuh Manager starts, it automatically launches the wazuh-db daemon along with other core services such as:

analysisd
remoted
execd
logcollector
modulesd

Once initialized, the daemon:

Opens the required SQLite databases.
Creates its Unix domain socket.
Waits for requests from other Wazuh processes.
Processes database operations throughout the lifetime of the Manager.

Administrators normally do not need to start Wazuh DB manually because it is managed as part of the Wazuh Manager service.

Background Service Behavior

After startup, Wazuh DB runs continuously in the background.

It remains idle until another Wazuh component submits a request.

This event-driven behavior minimizes CPU usage because the daemon performs work only when necessary.

Typical requests include:

Updating File Integrity Monitoring records
Retrieving agent metadata
Recording software inventory
Looking up vulnerability information
Updating Security Configuration Assessment results

Since the daemon processes requests continuously, administrators rarely interact with it directly.

Responsibilities

The wazuh-db daemon performs numerous internal operations, including:

Managing agent databases
Processing SQL operations
Synchronizing endpoint state
Maintaining SQLite transactions
Preventing concurrent write conflicts
Serving database requests from Wazuh modules
Returning query results through socket communication

These responsibilities allow the rest of the Wazuh platform to work with data without needing to understand the underlying storage implementation.

SQLite Databases

Rather than relying on a separate database server, Wazuh DB stores operational data in a collection of SQLite databases.

SQLite was selected because it offers:

Excellent reliability
Small resource requirements
ACID-compliant transactions
High read performance
Efficient write operations
Zero administration

Each database is optimized for the type of information it stores.

Agent Databases

Most monitored endpoints have their own database containing operational information collected from that specific agent.

These databases may contain records related to:

File Integrity Monitoring
Software inventory
Installed packages
Hardware details
Running processes
Open network ports
Labels
Security Configuration Assessment results

Separating endpoint information helps improve scalability because updates affect only the relevant agent database instead of one large shared file.

Global Database

In addition to individual agent databases, Wazuh maintains global databases that store information shared across the platform.

Examples include:

Shared metadata
Internal configuration information
Global synchronization data
Manager-level operational records

Keeping shared information separate from per-agent data simplifies maintenance and improves organization.

Schema Overview

Although SQLite is a relational database, Wazuh uses a schema specifically designed for operational security data rather than business analytics.

The schema is optimized for:

Fast lookups
Frequent updates
Incremental changes
Minimal storage overhead
Efficient indexing

Because the schema is managed internally by Wazuh, administrators typically do not modify database tables directly.

Storage Locations

The SQLite database files are stored locally on the Wazuh Manager within the Wazuh installation directories.

The exact locations vary slightly between versions, but they are generally found under the Wazuh installation path (such as /var/ossec/queue/db/ on Linux installations).

Administrators should avoid manually editing these database files while the Manager is running, as doing so can lead to database corruption or inconsistent state.

Unix Domain Socket

Instead of exposing a network database service, Wazuh DB communicates through a Unix domain socket.

This socket serves as the communication channel between Wazuh modules and the database daemon.

Because all communication remains on the local system, requests are both fast and secure.

Socket Communication

Whenever a Wazuh component needs information, it sends a request through the socket.

Examples include:

Retrieve agent information
Update file inventory
Store software packages
Query vulnerability data
Update SCA results

The daemon receives the request, performs the database operation, and returns the response over the same socket.

This design eliminates the need for external database connections.

Request/Response Model

The communication model follows a straightforward sequence:

Wazuh Module
      │
      ▼
Unix Domain Socket
      │
      ▼
wazuh-db
      │
      ▼
SQLite Database
      │
      ▼
Response Returned

Each request is processed independently, allowing multiple modules to interact with the database safely and efficiently.

Security Advantages

Using Unix domain sockets provides several security benefits over exposing a TCP database service.

These include:

No open network database ports
Reduced attack surface
Operating system file permissions protect the socket
Local-only communication
Lower risk of unauthorized remote access

This architecture follows the principle of least exposure by keeping internal services inaccessible from external systems.

Performance Benefits

Unix domain sockets are generally faster than local TCP/IP communication because they avoid much of the networking stack.

Benefits include:

Lower latency
Faster message passing
Reduced CPU overhead
Efficient inter-process communication
Better throughput under heavy workloads

These improvements help Wazuh maintain high performance even when thousands of agents are continuously sending updates.

Query Engine

The query engine is responsible for translating requests from Wazuh modules into database operations.

Rather than allowing arbitrary SQL queries, Wazuh DB accepts predefined commands that correspond to supported operations.

This abstraction simplifies development while improving security and consistency.

Command Parser

When a request reaches the daemon, the command parser interprets the operation.

Typical requests include:

Retrieve records
Insert new data
Update existing entries
Delete obsolete information
Synchronize endpoint state

After parsing the command, Wazuh DB determines which SQLite database should handle the request.

Database Operations

The query engine performs several types of database operations, including:

INSERT
UPDATE
SELECT
DELETE
Transaction management
Index lookups

These operations are optimized for the workloads generated by endpoint monitoring rather than general-purpose SQL usage.

Read/Write Requests

Most requests handled by Wazuh DB fall into two categories.

Read requests retrieve existing information, such as:

Agent inventory
File metadata
Installed packages
Vulnerability information

Write requests update information received from agents, including:

File changes
Inventory updates
Configuration assessments
Synchronization status

Because Wazuh agents continuously report new information, write operations occur frequently in active environments.

Response Handling

After completing a database operation, Wazuh DB returns the result to the requesting module.

Responses may include:

Query results
Confirmation messages
Status codes
Error information

The requesting service can then continue processing without needing direct access to the database itself.

How Wazuh DB Works

The following sequence illustrates how Wazuh DB processes information from the moment an endpoint sends data until other modules retrieve it.

Manager Starts Wazuh DB

When the Wazuh Manager starts, it launches the wazuh-db daemon automatically.

During initialization, the daemon:

Opens SQLite databases
Creates its Unix domain socket
Initializes internal resources
Waits for incoming requests

At this point, Wazuh DB is ready to receive requests from all Manager components.

Agent Sends Data

A Wazuh Agent continuously sends operational data to the Manager.

Examples include:

File changes
Installed software
Hardware inventory
Running processes
Open ports
Security configuration assessments
Vulnerability information

The Manager receives these updates and forwards the relevant information to the appropriate internal modules.

Data Is Processed

Modules such as Syscollector, File Integrity Monitoring, Vulnerability Detection, or SCA process the incoming data.

Instead of writing directly to database files, they submit requests to Wazuh DB through the Unix domain socket.

This separation keeps modules focused on analysis while Wazuh DB manages storage.

Database Updates

The Wazuh DB daemon validates each request before updating the appropriate SQLite database.

Typical operations include:

Adding new records
Updating changed values
Removing obsolete entries
Maintaining indexes
Committing transactions

SQLite ensures these updates remain consistent even if multiple requests arrive simultaneously.

Queries from Other Modules

Later, another Wazuh component may require the stored information.

For example:

Vulnerability Detection requests installed software.
FIM retrieves monitored file information.
Dashboard services request agent metadata.
Cluster synchronization checks endpoint state.

Rather than scanning files, these modules query Wazuh DB directly.

Results Returned

After executing the request, Wazuh DB returns the results through the Unix domain socket.

The requesting module then continues processing, generating alerts, updating inventories, or synchronizing information as needed.

The overall workflow can be summarized as follows:

Agent
   │
   ▼
Manager
   │
   ▼
Internal Module
   │
   ▼
Unix Socket
   │
   ▼
wazuh-db
   │
   ▼
SQLite Database
   │
   ▼
Response Returned

Data Stored in Wazuh DB

Although Wazuh DB does not store searchable alert data like the Wazuh Indexer, it maintains a wide variety of operational information that enables the platform to function efficiently.

Agent Metadata

Each monitored endpoint has associated metadata stored within Wazuh DB.

Typical metadata includes:

Agent ID
Agent name
IP address
Operating system
Version information
Registration status
Assigned groups
Connection details

This information allows the Manager to identify and manage every enrolled endpoint.

File Integrity Monitoring (FIM)

Wazuh DB stores File Integrity Monitoring information used to detect changes to monitored files.

Examples include:

File paths
Permissions
Ownership
Hash values
Modification timestamps
Monitoring state

This enables Wazuh to compare current file states against previously recorded baselines.

Syscollector Inventory

The Syscollector module stores extensive endpoint inventory data in Wazuh DB.

This includes:

Installed software
Running processes
Hardware inventory
Network interfaces
Listening ports
Operating system details
Installed packages

This inventory forms the foundation for vulnerability detection and asset visibility.

Vulnerability Detection Data

The Vulnerability Detection module relies heavily on information stored by Syscollector.

Wazuh DB maintains:

Installed package versions
Software metadata
Operating system versions
Vulnerability matching information
Scan state

Keeping this information readily available enables faster vulnerability analysis.

SCA Results

Security Configuration Assessment (SCA) results are also maintained within Wazuh DB.

Examples include:

Policy evaluations
Passed checks
Failed checks
Compliance scores
Benchmark results
Rule execution status

This allows Wazuh to track compliance changes over time without rescanning unchanged systems.

Labels and Metadata

Administrators can assign labels to agents for grouping and automation.

Wazuh DB stores information such as:

Environment tags
Department labels
Business units
Geographic locations
Custom metadata

These labels help organize large deployments and simplify policy assignment.

Agent Status Information

Wazuh DB continuously tracks operational information about each endpoint.

Examples include:

Connected/disconnected state
Last keepalive time
Agent version
Synchronization status
Upgrade status
Communication health

This information powers many of the health indicators shown in the Wazuh Dashboard.

Synchronization Data

In clustered deployments, Wazuh DB stores synchronization information that helps maintain consistency between manager nodes.

Examples include:

Replication state
Synchronization timestamps
Cluster metadata
Pending updates
Node-specific state information

This data helps ensure that managers within a cluster maintain a consistent view of monitored endpoints.

Related Guides:

Wazuh DB Directory Structure

Understanding where Wazuh DB stores its files can simplify troubleshooting, backups, and performance tuning.

The exact layout varies slightly depending on the deployment method and Wazuh version, but the overall structure remains consistent across installations.

The most important resources include:

SQLite database files
Unix domain socket
Queue directories
Internal database storage
Agent-specific databases

Administrators should avoid modifying these files directly while Wazuh is running.

Instead, interact with them through Wazuh services and supported administrative tools whenever possible.

Default Database Locations

By default, Wazuh stores its operational databases inside the Wazuh installation directory. On Linux, this is typically located under /var/ossec/.

The database directory contains SQLite files used by the Manager to maintain operational state, including agent inventories, File Integrity Monitoring (FIM) metadata, Security Configuration Assessment (SCA) data, and other module information.

Because these files are actively accessed by the wazuh-db daemon, direct modifications are not recommended.

Linux

On standard Linux installations, the most commonly referenced directories include:

/var/ossec/
├── queue/
│   ├── db/
│   └── db/wdb
├── var/
├── logs/
└── etc/

Some important locations include:

Directory	Purpose
`/var/ossec/queue/db/`	SQLite databases
`/var/ossec/queue/db/wdb`	Unix domain socket
`/var/ossec/logs/`	Wazuh logs
`/var/ossec/etc/`	Configuration files

The exact contents may vary slightly between Wazuh releases.

Docker

In Docker deployments, the database files reside inside the Wazuh Manager container.

For persistent storage, administrators typically mount the Wazuh data directories as Docker volumes.

This prevents operational databases from being lost when containers are recreated.

A simplified layout might resemble:

Container
│
├── /var/ossec/
│     ├── queue/
│     ├── logs/
│     ├── etc/
│     └── var/

Persistent volumes are strongly recommended for production deployments.

Related Guide: Fix Wazuh Docker Compose Deployment

Cluster Installations

In multi-node Wazuh clusters, every Manager node maintains its own local Wazuh DB instance.

This means:

Every master node has its own databases.
Every worker node has its own databases.
Synchronization occurs through cluster services, not by sharing SQLite files.

Because each node maintains local state, administrators should never attempt to copy live database files between cluster members.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Socket Locations

The Wazuh DB daemon communicates through a Unix domain socket rather than a TCP port.

A typical socket location is:

/var/ossec/queue/db/wdb

Other Wazuh daemons connect to this socket whenever they need to perform database operations.

Since the socket exists only locally, it is inaccessible from remote systems, improving the security of internal communications.

Important Database Files

Although Wazuh manages these files automatically, administrators may encounter them while troubleshooting.

Important database resources include:

Agent-specific SQLite databases
Global operational databases
SQLite journal or WAL files (depending on configuration)
Database lock files
Unix socket files

If a database becomes corrupted, Wazuh logs often provide diagnostic information before administrators consider rebuilding or restoring the affected database.

Communication Between Wazuh Components

Wazuh DB acts as a shared storage layer for several internal services.

Rather than interacting directly with SQLite databases, most Wazuh components communicate with the wazuh-db daemon through the Unix domain socket.

This architecture improves modularity, reduces database contention, and ensures consistent access to operational data.

The following sections explain how the major components interact with Wazuh DB.

Wazuh Manager

The Wazuh Manager orchestrates communication between agents, analysis modules, and Wazuh DB.

Whenever endpoint data arrives, the Manager routes it to the appropriate module, which then interacts with Wazuh DB as needed.

Examples include:

Registering new agents
Updating inventories
Recording file changes
Managing synchronization
Retrieving endpoint metadata

The Manager itself does not access SQLite files directly.

Analysisd

analysisd is responsible for decoding logs, applying rules, and generating alerts.

Although most alert processing occurs independently of Wazuh DB, analysisd may request operational information that helps evaluate security events.

Examples include:

Agent metadata
Configuration information
Inventory details
Endpoint state

This enables more informed rule processing without requiring separate storage mechanisms.

Remoted

remoted handles communication between Wazuh agents and the Manager.

As agents send updates, remoted receives the data and forwards relevant information to other modules, which in turn update Wazuh DB.

Typical interactions include:

Agent registration
Keepalive messages
Inventory updates
Event forwarding
Configuration synchronization

Syscheckd

The Syscheck (File Integrity Monitoring) module relies extensively on Wazuh DB.

Whenever monitored files change, Syscheck compares the new state against previously stored records maintained within the database.

Examples include:

File hashes
Ownership
Permissions
Timestamps
File attributes

This allows Wazuh to identify modifications without repeatedly rebuilding entire inventories.

Syscollector

Syscollector gathers detailed endpoint inventory information.

It stores information such as:

Installed software
Running processes
Hardware inventory
Operating system details
Network interfaces
Open ports

Nearly every inventory update generated by Syscollector ultimately becomes a database transaction handled by Wazuh DB.

Vulnerability Detector

The Vulnerability Detection module depends on inventory data maintained by Syscollector.

Instead of rescanning every endpoint each time, it retrieves existing software information from Wazuh DB before matching installed packages against vulnerability feeds.

This significantly reduces redundant processing while improving scan efficiency.

API Requests

Many requests received through the Wazuh REST API eventually access information stored in Wazuh DB.

Examples include:

Agent information
Inventory queries
Labels
Status information
Configuration data

The API itself does not communicate directly with SQLite databases.

Instead, it requests data through the appropriate internal services, which interact with Wazuh DB.

Dashboard Queries

The Wazuh Dashboard displays information gathered from several platform components.

When administrators view:

Agent inventories
Endpoint status
Installed software
File Integrity Monitoring data
Compliance results

the requested information often originates from data maintained by Wazuh DB before being presented through the Dashboard.

The Dashboard itself does not access database files directly; instead, it retrieves data through supported APIs and backend services.

Related Guide: How to Build a Wazuh Indexer Cluster

Wazuh DB Request Flow

Every database operation performed by Wazuh follows a predictable lifecycle.

Understanding this workflow helps explain how different modules safely share operational data without directly interacting with SQLite files.

Incoming Request

A request begins when a Wazuh component requires information or needs to update operational data.

Examples include:

An agent reports newly installed software.
File Integrity Monitoring detects a changed file.
Syscollector updates hardware inventory.
An administrator requests agent information through the API.

Rather than accessing SQLite directly, the component creates an internal database request.

Socket Communication

The request is transmitted through the Unix domain socket to the wazuh-db daemon.

Because communication remains entirely local, socket operations are:

Fast
Secure
Lightweight
Reliable

This approach avoids the overhead associated with network database protocols.

Query Parsing

After receiving the request, Wazuh DB validates and parses the command.

The parser determines:

Requested operation
Target database
Required tables
Necessary parameters
Permission checks

Only supported operations are accepted, reducing the possibility of malformed or unsafe database interactions.

SQLite Execution

Once validated, the daemon performs the appropriate SQLite operation.

Depending on the request, this may involve:

Reading records
Updating existing entries
Inserting new data
Deleting obsolete information
Executing transactions
Updating indexes

SQLite then commits the changes while maintaining transactional consistency.

Response Generation

After the database operation completes successfully, Wazuh DB prepares a response.

Responses may contain:

Requested records
Confirmation messages
Success status
Updated metadata
Query results

The response is returned through the Unix domain socket to the requesting component.

Error Handling

If a request cannot be completed, Wazuh DB returns an appropriate error rather than allowing silent failures.

Possible error conditions include:

Invalid commands
Missing databases
Locked database files
Corrupted SQLite databases
Permission problems
Invalid request parameters

Administrators should review the Wazuh Manager logs when investigating database-related errors.

Common Wazuh DB Commands

Although administrators do not usually communicate with Wazuh DB directly, understanding the types of operations it performs helps illustrate how the daemon interacts with the rest of the platform.

These commands represent logical operations rather than SQL statements executed manually.

Agent Queries

One of the most common operations involves retrieving information about monitored agents.

Typical requests include:

Agent registration details
Connection status
Assigned groups
Version information
Labels
Last keepalive timestamp

These queries help the Manager and API provide real-time endpoint information.

Global Database Queries

Some operations retrieve information that applies across the entire deployment rather than to a single endpoint.

Examples include:

Shared metadata
Internal configuration
Cluster information
Synchronization state
Manager-wide operational data

These queries support services that require a global view of the environment.

Reading Agent Information

Many internal modules regularly retrieve stored endpoint information.

Examples include:

Installed packages
Operating system details
Hardware inventory
Network interfaces
Compliance results
File metadata

Because this information is already indexed within SQLite, retrieval is significantly faster than rebuilding inventories from scratch.

Updating Records

As agents continuously report changes, Wazuh DB performs update operations such as:

Adding newly installed software
Updating file hashes
Recording hardware changes
Refreshing compliance results
Modifying agent metadata

Most production environments generate thousands of these updates every hour.

Retrieving Inventory Data

Inventory-related queries are among the most frequent database operations.

Modules commonly request:

Software inventories
Hardware information
Running processes
Listening ports
Installed packages
Operating system versions

This information supports vulnerability detection, compliance monitoring, and asset management.

Checking Database Status

When troubleshooting Wazuh DB, administrators often verify the health of the database service rather than inspecting SQLite files directly.

Common checks include:

Confirming that the wazuh-db daemon is running
Verifying socket availability
Reviewing Manager log files for database errors
Monitoring database growth and disk usage
Checking for SQLite corruption or lock issues

Regular health monitoring can help identify issues before they affect agent communication or module performance.

Wazuh DB Performance Optimization

Although Wazuh DB is designed to be lightweight and efficient, its performance can be affected by deployment size, hardware resources, database growth, and module configuration.

As organizations monitor more endpoints and collect additional telemetry, optimizing Wazuh DB helps maintain fast response times and reduces resource consumption.

The following best practices can improve the performance and scalability of Wazuh DB in both small and enterprise environments.

Keep Databases on Fast Storage

Because Wazuh DB performs frequent read and write operations, storage performance has a direct impact on the overall responsiveness of the Wazuh Manager.

For production deployments, consider:

Using SSD or NVMe storage instead of traditional HDDs
Avoiding slow network-mounted storage for active database files
Ensuring sufficient free disk space
Monitoring storage latency

Fast storage is especially important in environments with:

Thousands of agents
Large File Integrity Monitoring (FIM) deployments
Frequent Syscollector updates
Continuous vulnerability scans

Reducing storage latency allows SQLite transactions to complete more quickly, improving overall system performance.

Monitor Database Size

As agents continue reporting inventory, compliance, and monitoring data, database files naturally grow over time.

Regularly monitor:

Database file size
Disk usage
Available storage capacity
Growth trends

Unexpected database growth may indicate:

Excessive inventory collection
Overly broad FIM policies
Large numbers of inactive agents
Misconfigured monitoring rules

Proactive monitoring helps prevent storage exhaustion before it affects production systems.

Reduce Unnecessary Inventory Collection

Collecting more inventory data than necessary increases database activity without providing additional security value.

Review Syscollector settings and disable unnecessary inventory categories when appropriate.

Examples include limiting collection of:

Rarely used package information
Unneeded hardware details
Excessive process inventories
Unused network data

Reducing unnecessary data collection decreases:

Database writes
Disk usage
CPU utilization
Synchronization traffic

This is particularly beneficial in large-scale deployments.

Tune File Integrity Monitoring

File Integrity Monitoring is one of the largest contributors to Wazuh DB activity.

Poorly configured FIM policies can generate millions of database updates.

To improve performance:

Monitor only important directories
Exclude temporary files
Ignore cache directories
Reduce unnecessary recursion
Increase scan intervals where appropriate
Eliminate duplicate monitoring rules

Well-designed FIM policies reduce database load while maintaining effective security monitoring.

Related Guides:

Archive Old Agent Data

Inactive or decommissioned agents may leave behind operational data that is no longer needed.

Periodically:

Remove retired agents
Clean obsolete inventories
Archive historical information when required
Review stale records

Keeping only active endpoint data reduces database size and improves query performance.

Monitor Socket Activity

The Unix domain socket is the primary communication channel between Wazuh DB and other components.

If socket activity becomes unusually high, it may indicate:

Excessive inventory updates
Misconfigured modules
Agent communication loops
Heavy synchronization traffic
Unexpected bursts of endpoint activity

Monitoring Manager logs and overall system performance can help identify abnormal communication patterns before they become bottlenecks.

Update to Latest Wazuh Version

Each Wazuh release may include:

Performance improvements
SQLite optimizations
Bug fixes
Memory usage reductions
Improved synchronization logic
Database stability enhancements

Keeping Wazuh up to date ensures your deployment benefits from ongoing engineering improvements.

Before upgrading, always review the release notes and test updates in a staging environment whenever possible.

Related Guide: How to Upgrade a Wazuh Agent

Security Best Practices

Although Wazuh DB is an internal service, it stores operational data that is essential to the security platform.

Protecting its databases, communication channels, and supporting infrastructure helps maintain both system integrity and availability.

The following best practices reduce the risk of unauthorized access, accidental modification, and operational failures.

Restrict Database File Permissions

SQLite database files should be accessible only to the Wazuh services that require them.

Recommended practices include:

Limiting ownership to the Wazuh service account
Preventing unnecessary read or write permissions
Avoiding world-readable database files
Regularly auditing file permissions

Proper file permissions reduce the likelihood of accidental modification or unauthorized access.

Secure Unix Socket Access

Because all database communication occurs through the Unix domain socket, protecting socket permissions is just as important as protecting the database files themselves.

Verify that:

Only authorized Wazuh processes can access the socket
Socket permissions follow the principle of least privilege
Unnecessary local users cannot communicate with the service

Unlike network services, Unix sockets rely on operating system permissions for access control.

Limit Direct Database Modifications

Administrators should avoid manually editing SQLite database files while Wazuh is running.

Direct modifications can lead to:

Database corruption
Inconsistent records
Synchronization failures
Unexpected application behavior

Whenever possible, make changes through:

Wazuh configuration
Supported APIs
Official management tools
Agent enrollment and removal procedures

This ensures that all components remain synchronized.

Protect Backup Files

Database backups often contain sensitive operational information, including:

Agent inventories
System metadata
Compliance information
Endpoint details

Backup files should therefore be:

Encrypted when appropriate
Stored securely
Protected with access controls
Tested periodically for successful restoration

Treat backup files with the same level of protection as the production databases.

Monitor Database Integrity

Regular integrity checks can help detect problems before they impact production.

Monitor for:

SQLite corruption
Unexpected database growth
Failed transactions
Disk errors
Repeated database warnings in logs

Early detection reduces the likelihood of prolonged outages or data loss.

Use Principle of Least Privilege

The principle of least privilege is a widely accepted cybersecurity best practice that recommends granting only the minimum permissions necessary for each service or user.

For Wazuh DB, this means:

Restricting operating system permissions
Limiting administrative access
Preventing unnecessary database access
Using dedicated service accounts
Avoiding excessive privileges for automation scripts

Applying least privilege helps reduce the impact of compromised accounts or accidental administrative mistakes.

Keep Operating System Updated

Operating system updates often include:

Security patches
Filesystem improvements
SQLite library updates
Kernel fixes
Performance enhancements

Keeping the underlying operating system current helps protect both Wazuh DB and the overall deployment against known vulnerabilities.

Before applying updates in production, verify compatibility with your deployed Wazuh version.

Common Wazuh DB Problems and Solutions

Even though Wazuh DB is highly reliable, administrators may occasionally encounter operational issues caused by resource constraints, configuration errors, filesystem problems, or unexpected system failures.

The following are some of the most common problems and practical ways to resolve them.

Wazuh DB Service Not Running

Symptoms

Agent information is unavailable.
Inventory data stops updating.
Internal modules report database communication failures.
Manager logs contain Wazuh DB errors.

Possible Causes

Wazuh Manager failed to start correctly
Service crash
Startup dependency failure
Corrupted installation
Configuration issues

Solutions

Verify that the Wazuh Manager service is running.
Review Manager logs for startup errors.
Restart the Wazuh Manager service.
Check available system resources.
Reinstall damaged components if necessary.

Database Locked Errors

Symptoms

Database write failures
Delayed updates
SQLite lock messages
Inventory synchronization problems

Possible Causes

Long-running transactions
Unexpected service interruption
Filesystem issues
External processes accessing database files

Solutions

Avoid manually opening SQLite database files.
Restart affected Wazuh services if appropriate.
Verify storage health.
Check for abnormal process activity.
Review system logs for filesystem errors.

High CPU Usage

Symptoms

Increased Manager CPU utilization
Slow dashboard responses
Delayed inventory updates
Longer processing times

Possible Causes

Excessive File Integrity Monitoring
Large inventory collections
Massive agent deployments
Frequent synchronization
Resource-constrained hardware

Solutions

Reduce unnecessary inventory collection.
Optimize FIM policies.
Archive obsolete agent data.
Increase available CPU resources.
Review recent configuration changes.

Corrupted SQLite Database

Symptoms

Database errors in logs
Missing inventory information
Failed database queries
Unexpected service behavior

Possible Causes

Abrupt power loss
Disk failures
Filesystem corruption
Interrupted write operations

Solutions

Restore from a verified backup.
Investigate disk health.
Review filesystem integrity.
Follow the official recovery procedures.
Monitor for recurring storage problems.

Missing Agent Records

Symptoms

Agents appear incomplete.
Missing inventory data.
Empty software lists.
Missing metadata.

Possible Causes

Enrollment failures
Communication problems
Synchronization delays
Inventory collection disabled

Solutions

Verify agent connectivity.
Confirm successful enrollment.
Check Syscollector configuration.
Review Manager logs.
Force a new inventory collection if necessary.

Socket Connection Failures

Symptoms

Internal communication errors
Database request failures
Module timeouts
Failed API responses

Possible Causes

Missing Unix socket
Incorrect permissions
Wazuh DB service failure
Filesystem problems

Solutions

Verify the socket exists.
Check file permissions.
Confirm the wazuh-db daemon is running.
Restart the Wazuh Manager if necessary.
Review Manager logs for socket-related errors.

Slow Query Performance

Symptoms

Delayed inventory retrieval
Slow API responses
Dashboard latency
Increased processing time

Possible Causes

Large databases
Slow storage
Excessive monitoring
Heavy concurrent workloads

Solutions

Move databases to SSD or NVMe storage.
Archive obsolete data.
Reduce unnecessary monitoring.
Monitor database growth.
Scale the Wazuh deployment as needed.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Database Growth Issues

Symptoms

Rapid disk consumption
Large SQLite files
Reduced query performance
Storage alerts

Possible Causes

Excessive inventory retention
Large FIM deployments
Numerous inactive agents
High endpoint counts

Solutions

Remove inactive agents.
Tune inventory collection.
Optimize File Integrity Monitoring.
Monitor database growth regularly.
Increase storage capacity when appropriate.

Related Guide: How to Configure Wazuh Log Retention

Permission Denied Errors

Symptoms

Database access failures
Socket permission errors
Module startup failures
Missing inventory updates

Possible Causes

Incorrect file ownership
Misconfigured permissions
Security policy restrictions (such as SELinux or AppArmor)
Manual permission changes

Solutions

Restore the recommended ownership and permissions for the Wazuh installation.
Verify access rights on database directories and the Unix socket.
Review SELinux or AppArmor audit logs if applicable.
Restart affected Wazuh services after correcting permissions.

Monitoring Wazuh DB Health

Maintaining Wazuh DB health is essential for ensuring reliable agent management, accurate inventory collection, and stable operation of Wazuh modules.

Since many internal services depend on Wazuh DB, database issues can affect multiple areas of the platform, including vulnerability detection, File Integrity Monitoring, and endpoint visibility.

Regular health checks help administrators identify problems such as:

Database corruption
Socket failures
Excessive growth
Resource exhaustion
Service crashes
Synchronization problems

The following monitoring practices can help maintain a stable Wazuh DB environment.

Verify wazuh-db Status

The first step when troubleshooting Wazuh DB issues is confirming that the database daemon is running correctly.

The wazuh-db service runs as part of the Wazuh Manager stack.

If it stops unexpectedly, other components may fail to retrieve or update operational data.

On Linux systems, administrators can verify the Wazuh Manager service status:

systemctl status wazuh-manager

You can also verify running Wazuh processes:

ps aux | grep wazuh-db

A healthy system should show the wazuh-db process running continuously.

Common signs of a failed Wazuh DB service include:

Missing agent information
Inventory updates stopping
API requests returning incomplete data
Module communication errors
Database-related messages in logs

If the service repeatedly crashes, investigate logs before restarting repeatedly because the root cause may be related to storage problems, corrupted databases, or insufficient resources.

Related Guide: Fixing wazuh-db Worker Thread Crashes

Monitor Log Files

Wazuh logs provide valuable information about database activity and failures.

Important log locations include:

/var/ossec/logs/ossec.log

The Manager log may contain messages related to:

Database initialization
Socket communication
SQLite errors
Corrupted databases
Failed queries
Synchronization issues

Examples of problems that may appear in logs include:

Database locked errors
Unable to open database files
Permission failures
Invalid database operations

Regular log monitoring helps detect problems before they become service outages.

For large environments, consider integrating Wazuh logs into centralized monitoring platforms.

Related Guide: How to Configure Wazuh Log Retention

Check Socket Availability

The Unix domain socket is the communication bridge between Wazuh DB and other internal components.

If the socket becomes unavailable, services that depend on database access may stop functioning correctly.

A typical socket location is:

/var/ossec/queue/db/wdb

Administrators can verify that the socket exists:

ls -l /var/ossec/queue/db/

Common socket-related problems include:

Missing socket file
Incorrect permissions
Wazuh DB service failure
Filesystem issues

If the socket is missing, restarting the Wazuh Manager usually recreates it after the database daemon initializes successfully.

Validate SQLite Databases

SQLite databases used by Wazuh should remain consistent and healthy.

Signs of database corruption include:

Missing records
Failed queries
Repeated SQLite errors
Unexpected module failures

Administrators can validate SQLite databases using the SQLite integrity check command:

sqlite3 database_file.db "PRAGMA integrity_check;"

A healthy database returns:

ok

Before running any database checks:

Stop services that may access the database.
Create a backup copy.
Avoid modifying production database files directly.

Database validation should be part of troubleshooting rather than routine daily operation.

Monitor Resource Usage

Wazuh DB performance depends heavily on the resources available to the Wazuh Manager.

Monitor:

CPU usage
Memory consumption
Disk utilization
Disk latency
I/O wait
Process activity

Useful Linux commands include:

top

iostat

df -h

Resource problems may appear as:

Slow inventory updates
Delayed API responses
Increased dashboard latency
Agent synchronization delays

If resource usage remains consistently high, consider optimizing data collection or scaling the Wazuh deployment.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Track Database Growth

Database growth should be monitored continuously, especially in environments with many endpoints.

Rapid growth may indicate:

Excessive inventory collection
Overly broad FIM monitoring
Large numbers of inactive agents
Unexpected endpoint activity

Track:

Database directory size
Growth rate over time
Storage availability
Number of registered agents

Example:

du -sh /var/ossec/queue/db/

Unexpected growth should trigger a configuration review before storage exhaustion affects the Manager.

Wazuh DB in Clustered Environments

In large deployments, Wazuh uses a clustered architecture to distribute workload across multiple Manager nodes.

Understanding how Wazuh DB operates in this environment is important because each node maintains its own local database state.

Unlike distributed databases that share the same storage backend, Wazuh DB uses local SQLite databases on each Manager node and relies on Wazuh cluster communication mechanisms to maintain consistency.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Master and Worker Nodes

A Wazuh cluster typically contains:

One master node
Multiple worker nodes

The master node coordinates cluster-wide operations, while worker nodes handle agent connections and event processing.

Each node runs its own:

Wazuh Manager services
wazuh-db daemon
SQLite databases
Local socket communication

The Wazuh DB instance on each node operates independently rather than accessing a shared database file.

Database Synchronization

Because each cluster node maintains local databases, synchronization is required to keep endpoint information consistent.

The Wazuh cluster service handles synchronization of relevant information between nodes.

Synchronization helps maintain consistency for:

Agent metadata
Configuration state
Module information
Cluster-managed data

However, Wazuh DB itself is not a distributed database system. SQLite databases are local to each Manager node.

This design avoids the complexity and performance overhead associated with shared database locking.

Agent Assignment

In clustered environments, agents are assigned to specific worker nodes.

The assigned worker handles:

Agent communication
Event processing
Inventory updates
Database operations

The agent’s operational data is therefore primarily managed by the Wazuh DB instance running on that worker node.

If the worker becomes unavailable, cluster failover mechanisms help redistribute workload depending on the deployment configuration.

Cluster Communication

Wazuh cluster communication allows nodes to exchange operational information.

Communication between nodes supports:

Configuration synchronization
Agent information updates
Cluster state management
Module synchronization

This communication is separate from the local Unix socket communication used between Wazuh services and Wazuh DB.

The architecture can be summarized as:

             Wazuh Cluster Communication

        Master Node
             │
    ┌────────┼────────┐
    │        │        │
 Worker   Worker   Worker
 Node     Node     Node
    │        │        │
 wazuh-db wazuh-db wazuh-db
    │        │        │
 SQLite  SQLite   SQLite

High Availability Considerations

When designing a highly available Wazuh deployment, administrators should consider the relationship between cluster nodes and local databases.

Best practices include:

Deploy multiple worker nodes
Monitor cluster health
Maintain consistent configurations
Use reliable storage
Plan agent distribution carefully
Test node failure scenarios

Because each Manager node maintains local operational data, backups and recovery procedures should include every cluster member.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Wazuh DB vs Other Wazuh Storage Components

Wazuh uses multiple storage layers, each designed for a specific purpose.

Confusing these components can make troubleshooting difficult because operational data, security alerts, and configuration information are stored separately.

The table below highlights the differences between Wazuh DB and other major storage components.

Component	Purpose	Data Stored
Wazuh DB	Operational agent database	Agent state, File Integrity Monitoring data, inventory information, SCA results, module metadata
OpenSearch Indexer	Search and analytics engine	Security alerts, decoded events, indexed logs, dashboard visualization data
Archives	Raw event storage	Original events collected from agents, syslog sources, and monitored applications
Configuration Files	Platform and module configuration	Rules, decoders, agent settings, manager configuration, module parameters

Wazuh DB

Wazuh DB is the operational database layer of the platform.

It stores information required for internal functionality, including:

Agent state
Inventory records
FIM metadata
SCA results
Syscollector information
Synchronization data

It is optimized for fast internal access rather than analytics.

OpenSearch Indexer

The Wazuh Indexer is responsible for storing and searching security events.

It contains:

Alerts generated by detection rules
Security events
Indexed log data
Dashboard visualization data

Unlike Wazuh DB, the Indexer is designed for:

Searching
Filtering
Aggregation
Reporting
Visualization

Related Guide: How to Build a Wazuh Indexer Cluster

Configuration Files

Configuration files control how Wazuh operates.

Examples include:

ossec.conf
Rules files
Decoder files
Agent configurations
Module settings

Configuration files define behavior, while Wazuh DB stores operational information generated during runtime.

Understanding the Storage Separation

A simplified view of Wazuh storage architecture looks like this:

                 Wazuh Agent
                      │
                      ▼
              Wazuh Manager
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
   Wazuh DB       Archives       Configuration
       │
       ▼
Agent State,
Inventory,
FIM,
SCA

                      │

                      ▼

             OpenSearch Indexer

                      │

                      ▼

              Wazuh Dashboard

This separation allows each component to perform the task it was designed for:

Wazuh DB manages operational state.
Indexer provides search and analytics.
Archives preserve raw events.
Configuration files define platform behavior.

Understanding these differences is critical when troubleshooting Wazuh performance, scaling deployments, and maintaining a reliable security monitoring environment.

Real-World Example

Scenario

A large enterprise manages more than 12,000 Linux, Windows, and macOS endpoints using a clustered Wazuh deployment across multiple Security Operations Center (SOC) environments.

Initially, the organization deployed Wazuh with default database and monitoring configurations.

As endpoint coverage expanded, security analysts began noticing several performance issues:

Agent inventory updates were taking longer to complete.
File Integrity Monitoring (FIM) scans were generating delays.
Vulnerability detection results were not appearing as quickly.
Dashboard information appeared less responsive during peak activity periods.

The security team began investigating the Wazuh Manager nodes and discovered that the wazuh-db service was processing a much larger volume of operational data than originally expected.

The main contributors were:

Continuous Syscollector inventory updates from thousands of endpoints.
Broad FIM monitoring policies covering unnecessary directories.
Large numbers of inactive agent records.
Increasing SQLite database sizes over time.
High disk I/O caused by frequent database transactions.

Because Wazuh DB stores operational information such as agent state, inventory data, FIM metadata, and SCA results, the database layer became a critical performance component as the environment scaled.

Identifying the Bottleneck

The security team reviewed several areas of the deployment:

Database Storage Performance

The Wazuh DB files were running on slower storage originally designed for general-purpose workloads.

High disk latency caused SQLite write operations to complete more slowly, increasing the time required to process inventory and FIM updates.

Syscollector Configuration

The organization had enabled extensive inventory collection across all endpoints, including data that provided limited security value.

Examples included:

Frequent hardware inventory updates
Excessive process collection
Unnecessary package scans

These settings generated additional database writes without significantly improving visibility.

Inactive Agent Data

Over time, thousands of retired systems remained registered in the environment.

Although these endpoints were no longer actively monitored, their database records continued consuming storage space and increasing maintenance overhead.

File Integrity Monitoring Scope

The original FIM configuration monitored large portions of endpoint filesystems.

This resulted in:

Excessive file change events
Increased database updates
Higher CPU usage
Additional synchronization traffic

Optimization Actions

To resolve the performance issues, the organization implemented several improvements.

Moving Wazuh DB Storage to High-Performance SSDs

The organization migrated Wazuh DB storage from traditional disks to enterprise SSD storage.

Benefits included:

Faster SQLite transactions
Lower database write latency
Improved inventory update speed
Reduced I/O wait
Better Manager responsiveness

Because Wazuh DB performs frequent small read/write operations, faster storage provided immediate performance improvements.

Optimizing Syscollector Scan Intervals

The security team reviewed Syscollector settings and adjusted collection schedules based on operational requirements.

Changes included:

Increasing scan intervals
Removing unnecessary inventory categories
Reducing duplicate data collection

This reduced the number of database updates generated by endpoints while maintaining sufficient asset visibility.

Cleaning Up Inactive Agent Databases

The organization performed regular maintenance to remove outdated endpoint records.

Actions included:

Removing decommissioned agents
Reviewing stale registrations
Cleaning unnecessary database entries
Updating asset management procedures

This reduced database growth and improved query performance.

Monitoring Database Growth

The security team implemented regular Wazuh DB health monitoring.

They tracked:

Database directory size
Storage consumption
Growth trends
Resource utilization
Database-related errors

This allowed administrators to identify abnormal growth before it affected production performance.

Results After Optimization

After implementing these improvements, the organization achieved:

Faster agent inventory updates
Reduced FIM processing delays
Improved module synchronization
Lower disk utilization
More responsive Wazuh Dashboard performance
Better scalability across the cluster

The biggest lesson from this deployment was that Wazuh DB performance becomes increasingly important as endpoint counts grow.

While Wazuh is capable of monitoring thousands of systems, database storage, collection policies, and maintenance practices must scale alongside the environment.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Frequently Asked Questions (FAQ)

Question: What is Wazuh DB?

Wazuh DB is an internal database service used by the Wazuh Manager to store and retrieve operational information about monitored endpoints.

It manages data such as:

Agent metadata
File Integrity Monitoring information
Syscollector inventory
Security Configuration Assessment results
Synchronization information

Unlike the Wazuh Indexer, Wazuh DB is not designed for searching security alerts or analyzing large volumes of event data.

Question: Is Wazuh DB a SQL database?

Yes, Wazuh DB uses a relational database model internally, but it is not a traditional standalone SQL database server.

It does not operate like:

MySQL
PostgreSQL
Microsoft SQL Server

Instead, it uses SQLite as an embedded database engine managed by the wazuh-db daemon.

Question: Does Wazuh DB use SQLite?

Yes.

Wazuh DB uses SQLite because it provides:

Low resource consumption
Reliable transactions
Fast local queries
No external database server requirements
Simple deployment

SQLite is well suited for Wazuh’s operational storage requirements.

Question: Where are Wazuh DB files stored?

On Linux installations, Wazuh DB files are typically stored under:

/var/ossec/queue/db/

This directory contains SQLite databases and supporting database resources.

In Docker deployments, the location exists inside the Wazuh Manager container and should normally be mapped to persistent storage.

Related Guide: Fix Wazuh Docker Compose Deployment

Question: Can I Query Wazuh DB Directly?

Although Wazuh DB uses SQLite internally, administrators generally should not query or modify database files directly in production environments.

Direct access can cause:

Database locking
Corruption
Inconsistent data
Service failures

Use supported interfaces such as:

Wazuh API
Dashboard
Official management commands

whenever possible.

Question: What Data Does Wazuh DB Store?

Wazuh DB stores operational endpoint information required by internal modules.

Examples include:

Agent metadata
Agent status
File Integrity Monitoring records
Software inventory
Hardware inventory
Network information
SCA results
Vulnerability-related inventory data
Synchronization information

Question: Is Wazuh DB Used to Store Alerts?

No.

Wazuh DB does not store security alerts.

Alert storage is handled by the Wazuh Indexer, which is optimized for:

Searching
Filtering
Aggregation
Dashboard visualization

Wazuh DB focuses on operational state and endpoint information.

Question: How Does Wazuh DB Communicate With Other Components?

Wazuh DB communicates with internal Wazuh services through a Unix domain socket.

The general communication flow is:

Wazuh Module
      │
      ▼
Unix Domain Socket
      │
      ▼
wazuh-db
      │
      ▼
SQLite Database
      │
      ▼
Response Returned

This design provides fast local communication without exposing a database service over the network.

Question: Can Wazuh DB Become Corrupted?

Yes, although corruption is uncommon.

Possible causes include:

Unexpected system shutdowns
Disk failures
Filesystem corruption
Interrupted write operations
Manual database modifications

Symptoms may include:

Missing records
Database errors
Failed module operations
Inventory synchronization issues

Administrators should maintain backups and monitor storage health.

Question: How Do I Back Up Wazuh DB?

A Wazuh DB backup should include the database files stored in the Wazuh installation directory.

Recommended practices include:

Stop Wazuh services before copying active databases
Store backups securely
Encrypt backup files
Test restoration procedures regularly

For production environments, backup strategies should include both Wazuh DB data and configuration files.

Question: Does Every Wazuh Agent Have Its Own Database?

Yes, Wazuh maintains agent-specific database information.

Separating agent data helps improve scalability by preventing one large database from becoming a bottleneck.

Each endpoint can maintain information related to:

Inventory
FIM data
SCA results
Operational state

Question: How Does Wazuh DB Work in a Cluster?

In a Wazuh cluster, every Manager node maintains its own local Wazuh DB instance.

The cluster architecture includes:

One master node
Multiple worker nodes
Local SQLite databases on each node

Cluster services synchronize required information between nodes, but Wazuh DB is not a shared distributed database.

Conclusion

Wazuh DB is a critical but often overlooked component of the Wazuh architecture.

While the Wazuh Dashboard and Indexer receive much of the attention, Wazuh DB provides the operational foundation that allows the platform to manage thousands of endpoints efficiently.

Unlike traditional database systems designed for analytics or reporting, Wazuh DB is a lightweight embedded database service optimized for endpoint state management.

Using SQLite as its storage engine, it provides fast and reliable access to operational information without requiring a separate database server.

Throughout this guide, we explored how Wazuh DB:

Stores agent state information
Maintains File Integrity Monitoring data
Supports Syscollector inventory
Stores Security Configuration Assessment results
Provides operational data for internal Wazuh modules
Supports large-scale clustered deployments

Understanding Wazuh DB architecture is essential for troubleshooting performance problems, designing scalable deployments, and maintaining a reliable security monitoring platform.

As your Wazuh environment grows, regularly monitor:

Database health
Storage performance
Database growth
Socket communication
Resource usage

Following security best practices, protecting database files, maintaining proper permissions, and keeping Wazuh updated will help ensure long-term stability.

For organizations running thousands of endpoints, Wazuh DB optimization is not just a maintenance task, it is a key part of building a scalable and dependable security operations platform.

More resources: