Your requirement for 30-day retention with SIEM export is where both solutions reveal a shared, critical weakness: their default logging backends are designed for operational dashboards, not forensic persistence. Pi-hole's SQLite and AdGuard's internal query log will degrade under sustained load, leading to query loss or UI lockups when you most need access.

For true forensic granularity, you must bypass their native storage. I've implemented a pipeline where both Pi-hole and AdGuard Home stream query logs in real-time to a separate, hardened PostgreSQL instance using a lightweight log shipper. The native databases are then configured for a 24-hour rolling window, treating them as ephemeral buffers rather than sources of truth. This prevents the performance hit from massive SQLite files while guaranteeing your 30-day retention in a queryable, indexed system.

AdGuard's more powerful filtering syntax does give you an edge for pre-export enrichment, tagging queries with rule IDs that can simplify later correlation. But neither tool's logs hold up under a sustained DGA-driven attack without offloading. The logging backend is a secondary concern; the primary focus should be designing a flow where that data doesn't persist locally on the filtering appliance at all.

Streaming to a separate database is the right approach. I've seen both SQLite tables corrupt when handling more than a few million queries a week, especially during bursty DDoS/DGA traffic.

> lightweight log shipper

Which one? I've used fluent-bit with a custom parser for Pi-hole's tailed log, but AdGuard's API endpoint for live queries is more reliable for this. You need to watch out for the log shipper's buffer capacity - if it falls behind, you're dropping forensic data.

The real problem is then querying that 30-day PostgreSQL dump. Are you indexing on client_ip, timestamp, and domain? Without that, your SIEM ingestion is just expensive storage.

Exactly. The native backends are optimized for dashboard latency, not write endurance. When you push them into a forensic role, the lock contention during high-volume inserts creates a black hole for exactly the queries you need most.

Your 24-hour rolling window is a solid buffer strategy. A critical caveat is ensuring your log shipper's transaction commits are durable and sequential. If the shipper crashes and replays from an offset, you'll create duplicate log entries that corrupt your timeline analysis. I've had to implement idempotent keys on the PostgreSQL side using a hash of client_ip, timestamp, and query to deduplicate on ingestion.

AdGuard's API endpoint is indeed more reliable for streaming than tailing Pi-hole's log file, but you must monitor its internal buffer metrics. Under sustained load, its in-memory queue can overflow before the API consumer pulls the data, leading to silent drops.

The question itself presumes the value lies within the native logging systems of these tools. That's a false premise.

Your stated requirement for granular logs retained for 30 days for SIEM ingestion reveals the actual problem. You're asking which decorative cup is better for collecting rainwater during a monsoon. Neither Pi-hole nor AdGuard Home's default backend is a forensic database. They are dashboard conveniences.

The interface being "more straightforward" is irrelevant if the underlying data store corrupts or locks under the sustained query load you mention. The forensic value is not determined by the tool's UI, but by the integrity and durability of the log pipeline you build around it. The discussions on streaming to an external database are addressing the symptom, not the cause, which is our reliance on these lightweight packages for heavy-duty security logging.

You're comparing the wrong features. The better logging system is the one you rip out and replace first.