Database activity monitoring buyer's guide: how to evaluate

This database activity monitoring buyer’s guide gives you a neutral way to compare DAM products: the criteria that decide a project, the questions to put to every vendor, a weighted scoring template and a proof-of-concept plan you can run the same way for each shortlisted product. It is written for security leaders, DBAs and procurement teams choosing a tool for Oracle, PostgreSQL, SQL Server, MySQL or managed cloud databases. Where it helps, each criterion also notes what SWOT DAM does, taken from its documentation, so you can see a worked answer.

A DAM proof of concept is a time-boxed trial in which a database activity monitoring product runs against representative databases, with agreed test scenarios and pass criteria, to confirm that its coverage, detections, operational impact and audit evidence meet your requirements before purchase.

Define your requirements before you meet vendors

Write down four things before the first demo. They remove products quickly and stop the evaluation drifting towards whichever feature was shown last.

1. Engines and versions in scope, including managed services such as Amazon RDS or Azure SQL.
2. Block or detect. If statements must be stopped before they run, you need an inline component. If detection and fast response are enough, out-of-band options open up.
3. What may change on database hosts and connection paths. Some teams cannot install agents or reroute client connections; others can.
4. Evidence requirements. Which frameworks you report against, how long records must be kept and who may read them. NIST SP 800-53 control AU-2, for example, asks you to justify that the event types you log are adequate “to support after-the-fact investigations”.

If you need a refresher on the architectures behind these choices, our guide to what database activity monitoring is compares native audit, network, agent and proxy collection.

Database activity monitoring evaluation criteria

These criteria cover what most DAM projects turn on. The right-hand column gives SWOT DAM’s documented answer as an example of the detail to expect from any vendor.

Criterion	What to establish	SWOT DAM’s documented answer
Collection architecture	How activity leaves the database, and what runs on the host or in the path	Read-only collectors poll each native audit trail; no inline proxy, nothing installed on the database host
Engine coverage	Engines, versions and the mechanism for each	Oracle 19c to 23c (Unified Audit), PostgreSQL 14 to 16 (pgAudit), SQL Server 2017 to 2022 (SQL Server Audit), MySQL 8.0 and MariaDB (server_audit), RDS and Aurora (CloudWatch); Azure SQL and Google Cloud SQL also covered
Prevention	Whether it can block, and how	Detects and alerts; it does not block. LiveOps can end a session after two confirmations
Data handling	Whether business records are read or copied	Never connects to user data tables; reads catalog metadata, audit views and system views
Sensitive data discovery	Method, frequency, where analysis runs	Classifies new columns every 24 hours from names and types, using OpenAI, Azure OpenAI or a local Ollama model
Behaviour analytics	Baselines versus fixed rules	Risk score 0 to 100 per identity against its own 30-day baseline
Alert rules	Built-in detections and thresholds	Schema changes, privilege escalation, more than 5 failed logins in 60 seconds, single queries reading over 50,000 rows from PII or financial tables
Integrations	SIEM, ticketing and email formats	Splunk HEC, CEF over syslog for QRadar and ArcSight, webhooks, SMTP email
Evidence	Export formats and integrity checks	Signed CSV and PDF exports with a SHA-256 receipt
Access control	Roles, SSO, separation of duties	Four roles, including auditor and operator roles with no SQL text or user identities; SAML 2.0 or OIDC SSO
Deployment	Hosting model and sizing	Self-hosted on Docker Compose or as a Windows service; proof-of-concept tier of 1 to 5 databases on 4 vCPU, 8 GB RAM, 100 GB NVMe

Sources for the SWOT DAM column: the SWOT DAM documentation and the SWOT DAM product page.

Questions to ask any DAM vendor

Send the same list to every vendor and ask for written answers with links to documentation.

Architecture and impact

• What software runs on the database host, if any, and how is it patched and upgraded?
• Does any component sit in the client connection path? What happens to connections if it fails?
• How are local connections, such as a DBA on the server itself, captured?
• How are encrypted client sessions handled?

Coverage

• Which engines and versions are supported today, and through which mechanism for each?
• What audit configuration do you require on each engine, and what is its documented overhead? As an example, the pgAudit README notes that audit logging may noticeably affect latency.

Detection and response

• Which detections ship by default, and what are their thresholds?
• Are baselines per identity, per role or global? How long do they take to form?
• What response actions are available, and what safeguards stop an operator ending the wrong session?

Data and privacy

• Does the product read or store business data values? Where is the audit store hosted?
• If AI features are used, what is sent to the model, and can the model run inside our network?

Evidence and access

• How can an auditor verify an export has not been altered?
• Can an auditor role see evidence without seeing SQL text or user identities?

DAM scoring table template

Agree weights before demos and score each product from 0 (not met) to 5 (fully met, demonstrated in the proof of concept). Multiply score by weight and total. The weights below are an example; set your own.

Criterion	Weight (%)	Vendor A score (0 to 5)	Vendor B score (0 to 5)	Evidence reference
Engine and version coverage	15
Collection architecture fits constraints	15
Prevention or detection fit	10
Detection quality in PoC scenarios	15
Sensitive data discovery	10
Evidence integrity and export	10
Integrations (SIEM, ticketing)	10
Access control and SSO	5
Deployment and operating effort	10
Total	100

Record the evidence for every score: a document link, a PoC test number or a screenshot. A score without evidence is an opinion.

How to run a DAM proof of concept

Run the same plan for every product, on the same database copy, with the same audit settings.

1. Prepare. Choose one database per major engine, production-like and masked. Record engine versions and audit configuration.
2. Install. Time the installation and note every change made to hosts, networks and database accounts.
3. Baseline. Let the product observe normal workload, including at least one batch or month-end cycle if you can.
4. Run scenarios. Execute each test below and record whether it was captured, alerted, attributed to the right identity and exported.
5. Measure impact. Compare database response times and host resource use with and without monitoring, under the same workload.
6. Test evidence. Export a filtered audit report and have your auditor check it for completeness and integrity.
7. Score. Fill in the scoring table with evidence references, and hold a debrief with DBAs, analysts and audit.

#	Scenario	Expected result
1	Six failed logins in under a minute from one address	Brute-force alert naming user and address
2	GRANT of a DBA or superuser role to an application account	Privilege escalation alert
3	DROP TABLE outside an approved change window	Schema change alert
4	Bulk SELECT from a table holding personal data	Mass-read alert on the sensitive table
5	Normal application account working at an unusual hour from a new network	Raised risk score for that identity
6	New table created with PII-like column names	Columns classified as sensitive at the next scan
7	Auditor exports a filtered report	Export opens, matches the filter and passes the integrity check

What other vendors document about their architectures

Read each vendor’s own architecture documentation and ask them to confirm it for the version you would buy. Two examples show how different the starting points are. IBM describes its Guardium S-TAP as “a lightweight software agent installed on database servers and file servers” that forwards activity to a Guardium collector. Oracle documents three Database Firewall modes: proxy, which can monitor and block SQL, and out-of-band and host monitor modes, which can monitor and alert but cannot block.

Native audit has its own documented caveats. Microsoft notes that members of the sysadmin role can tamper with any audit component, which is why the audit copy should live outside the database. If IBM Guardium is on your shortlist, our SWOT DAM vs IBM Guardium evaluation guide sets out the questions side by side. IBM Guardium, Oracle and SQL Server are trademarks of their respective owners.

Next steps

A database activity monitoring buyer’s guide is only useful if you apply it the same way to every product: fix requirements and weights first, ask every vendor the same questions, and decide on proof-of-concept evidence. If you want SWOT DAM in your proof of concept, see the database security solution page or book a demo on your own engines.