DBSheriff isn't ported to each engine as an afterthought. Every one of the twelve is built against that engine's own native security and audit features, and every one has been validated end-to-end against real, live infrastructure — not simulated, not mocked.
Every engine in this list has been through a full disposition-and-detection test pass against a real, live instance of that platform — a real Amazon RDS database, a real Snowflake account, a real Databricks workspace, a real on-premises server — running realistic, finance-domain datasets built for the purpose. Detection, automatic response, evidence collection and account recovery were each exercised end to end and confirmed against the platform's own ground truth, not just DBSheriff's own logs.
Every engine was tested against real, running database instances on the actual cloud platform or on-premises stack it's meant to protect, using realistic synthetic financial data built specifically for the purpose — never a customer's real production data. Detection was confirmed to actually score the risk correctly, automatic response was confirmed to actually stop the query and land in the engine's own audit trail, and account recovery was confirmed to actually restore access. That's the bar every engine below had to clear.
DBSheriff never treats an engine as a generic SQL socket. Each one gets first-class integration with the security and audit capabilities that engine already ships — so a Snowflake deployment gets Snowflake's own masking policies and access history, an Oracle deployment gets Oracle's own Unified Audit and Data Redaction, and so on.
Whichever mix of these twelve you run, your team sees one console, one detection model, one compliance report format, and one set of controls. You don't re-learn the product for every database you add.
Deployment models differ — a managed cloud warehouse doesn't have "sessions" the way a traditional database does — but the capability set doesn't shrink to fit the weakest engine. Real-time detection, data classification, automatic response, compliance evidence, posture scanning, and account governance are available on every one of the twelve.
| Capability | Availability |
|---|---|
| Real-time statement visibility & scoring | ✓ All 12 engines |
| Sensitive data discovery & classification | ✓ All 12 engines |
| Automatic query termination | ✓ All 12 engines |
| Account lock / unlock on burst or repeat offense | ✓ All 12 engines |
| Honeytoken (canary table) absolute protection | ✓ All 12 engines |
| Compliance reporting (PCI DSS 4.0, SOC 2, NIST 800-53, CIS) | ✓ All 12 engines |
| Continuous posture & configuration drift scanning | ✓ All 12 engines |
| Named, blocking-session lock-wait detection | PostgreSQL & Redshift — deepest coverage; partial elsewhere |
| Automatic multi-database discovery on one server | PostgreSQL — every other engine is registered per database/catalog explicitly |
| Per-query cost-based protection | Snowflake, BigQuery, Databricks — the cloud-billed warehouses |
| Native time-travel / data-recovery visibility | Snowflake, Databricks, BigQuery |
These differences are almost always real, structural facts about how each platform itself works — not gaps in DBSheriff's own coverage. Where an engine has no concept of a "session" to lock, or exposes no query-level lock-wait data at all, DBSheriff adapts to what the platform actually gives it rather than faking a signal that isn't real.
The full capability breakdown — every category of risky SQL behavior DBSheriff stops, and how the automatic response ladder works.
View the full feature guide → Request a Demo