Operations

DBVoyeur operates by passively capturing the SQL traffic between application clients and the database server. There is no agent inside the database, no client-side instrumentation, and no production configuration to change.

Deployment topologies

Topology	Where DBVoyeur runs	DB host overhead	When to choose it
Co-resident	On the database host itself	~1–2% of one core	Default. Simplest to deploy, works in every environment, including cloud VMs without SPAN ports.
Separate host	A dedicated Linux host on the same subnet, receiving a mirrored copy of the database traffic	Effectively zero	Tight CPU budgets, regulated environments where nothing additional is permitted on the DB host.

Two things depend on where DBVoyeur runs, and both are worth settling before you choose a topology.

Mirrored traffic and encrypted SQL are mutually exclusive. A mirrored feed delivers exactly the same bytes a local capture would, so it is subject to the same limit: where a connection uses a modern cipher suite, the session keys are never transmitted and the SQL cannot be recovered from the network traffic by any product, at any capture point. Recovering statement text from encrypted connections requires capturing on the database host itself. If your listeners are encrypted and you need full SQL detail, a separate-host or mirrored deployment cannot provide it — see TLS.

Shared-memory connections require DBVoyeur on the database host. A client connecting over shared memory never sends a packet: the request is handed to the server through a memory segment the two processes share, so there is nothing on any network interface to observe, on any host. Local clients, batch jobs and stored-procedure work frequently connect this way, and on a separate-host or mirrored deployment that traffic is invisible — not partially captured, but absent entirely.

What gets captured

Field	Meaning
SQL text	The full text of every prepared and executed statement, normalised for grouping by template if desired.
Bind values	Parameter values bound to each execution (configurable per database and per table for sensitive data).
Response time	Wire-measured time from the request leaving the client to the response leaving the server.
Rows returned / affected	Result-set size for queries, affected-row count for DML.
Client identity	Source IP, source port, database user, application name where the driver supplies it.
Session identity	Database session id, server PID where applicable, transaction boundaries.
Errors	Server error code, error message, and the statement that triggered it.
Wait events	Where the database surfaces them at the wire, the wait class on each round trip.

The repository

Per-transaction data is volumetric. A modestly busy production database easily generates tens of millions of measured transactions per day. DBVoyeur ships with a repository architecture explicitly designed for that volume: rolling partitions, automatic aggregation tiers, and a SQL-searchable summary layer that lets the operator walk from a user complaint (“last Tuesday at 10:42 the checkout page was slow”) to the exact statements involved in seconds.

The repository is itself queryable in SQL, so existing reporting, alerting, and BI tools work against it directly. Common patterns — top-N slow statements per hour, regression of a statement’s P99 over a release, top callers of a given table — are all ordinary SQL queries.

Configuration model

A single DBVoyeur instance can monitor multiple database types and multiple database instances simultaneously. Configuration is declarative: each monitored target is described by host, port, and database flavour. DBVoyeur tracks which targets are being captured, which are configured but not yet live, and the wire-format version in use on each.

Operational behaviour

Property	Behaviour
Read-only	Never modifies any traffic in either direction. Pure observer.
Fail-safe	If DBVoyeur stops, the application keeps working. There is no in-line path for database traffic when the capture is passive.
Bounded resource use	Capture, decode and repository writers run in bounded queues with backpressure. Under sustained overload, DBVoyeur sheds the oldest pending events first and continues; it never blocks the wire.
Restart-safe	The repository tolerates DBVoyeur restarts mid-stream. A restart is visible as a gap in the timeline, not a corruption.
Bind-value redaction	Per-database and per-table rules can redact bind values entirely, hash them, or pass them through unchanged.