Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.anomalyarmor.ai/llms.txt

Use this file to discover all available pages before exploring further.

Connect once, monitor everything. Add your database credentials and AnomalyArmor continuously monitors for schema changes, stale data, and quality issues, without installing anything in your infrastructure. Your data stays in your database. We only read metadata (table names, column types, timestamps) through a secure, read-only connection.

​
Supported Databases

AnomalyArmor supports the most popular data platforms used by modern data teams:
DatabaseVersionKey Features
PostgreSQL12+Tables, views, schemas, materialized views
MySQL5.7+Tables, views, schemas
SQL Server2012+Tables, views, schemas, Azure SQL Database
Amazon RedshiftAnyTables, views, external tables (Spectrum)
DatabricksUnity CatalogCatalogs, schemas, Delta tables, views
ClickHouse21.8+Tables, views, materialized views, dictionaries

PostgreSQL

Including RDS, Aurora, Supabase, and self-hosted

MySQL

Including RDS, Aurora MySQL, PlanetScale, and self-hosted

SQL Server

Including Azure SQL Database and on-premise

Amazon Redshift

Provisioned clusters and Serverless workgroups

Databricks

Unity Catalog with Delta Lake support

ClickHouse

Including ClickHouse Cloud

​
How Data Sources Work

When you add a data source, AnomalyArmor:
  1. Stores credentials securely: Encrypted with AES-256
  2. Tests connectivity: Verifies we can reach your database
  3. Awaits discovery: No scanning until you trigger it
Data source lifecycle from connection to monitoring

​
What We Access

AnomalyArmor only queries metadata from your databases:
We AccessWe Never Access
information_schemaYour actual data
System catalogsRow contents
Table/column namesPII or sensitive values
Data typesBusiness data
Timestamps (for freshness)Query results
See Security Overview for detailed information about our security practices.

​
Adding a Data Source

​
Quick Steps

  1. Navigate to Data Sources in the sidebar
  2. Click Add Connection
  3. Select your database type
  4. Enter connection credentials
  5. Click Test Connection
  6. Click Save
For detailed instructions, see the guide for your specific database:

​
Managing Data Sources

​
Editing Connections

To update a data source:
  1. Go to Data Sources
  2. Click on the connection name
  3. Click Settings
  4. Update credentials or configuration
  5. Click Save
Changing credentials will require re-testing the connection. Scheduled discoveries may fail if credentials are incorrect.

​
Deleting Connections

To remove a data source:
  1. Go to Data Sources
  2. Click on the connection name
  3. Click Settings → Delete Connection
  4. Confirm deletion
What gets deleted:
  • The connection and credentials
  • Discovery schedule
  • Associated alert rules (optional)
What’s preserved:
  • Historical schema change data
  • Audit logs

​
Connection Status

Each data source shows its status:
StatusMeaning
ConnectedLast discovery succeeded
ErrorConnection or permission issue
Never RunDiscovery hasn’t been triggered yet
RunningDiscovery in progress

​
Network Requirements

AnomalyArmor connects outbound to your databases. You’ll need to:

​
1. Allow AnomalyArmor IPs

Allowlist our static IP addresses in your firewall or security group: 
AnomalyArmor IP Addresses:
34.xxx.xxx.xxx/32
34.xxx.xxx.xxx/32
View current IPs in Settings → Security in your dashboard.

​
2. Open Database Port

Ensure the database port is accessible:
DatabaseDefault Port
PostgreSQL5432
MySQL3306
SQL Server1433
Amazon Redshift5439
Databricks443 (HTTPS)
ClickHouse8443 (HTTPS)

​
3. SSL/TLS Configuration

We recommend (and often require) encrypted connections:
  • PostgreSQL: SSL Mode = require
  • MySQL: SSL Mode = require
  • SQL Server: Encryption enabled (required for Azure SQL)
  • Amazon Redshift: SSL required by default
  • Databricks: Always HTTPS
  • ClickHouse: Port 8443 for HTTPS

​
Enterprise Options

For enhanced security, Enterprise customers can use:

​
VPC Peering

Direct network peering between your AWS VPC and AnomalyArmor:
  • No public internet exposure
  • Lower latency
  • Private IP connectivity
Connect via AWS PrivateLink:
  • Fully private connectivity
  • No firewall changes needed
  • Traffic stays on AWS backbone
Contact sales@anomalyarmor.ai for Enterprise options.

​
Best Practices

​
Use Read-Only Credentials

Always create a dedicated, read-only user for AnomalyArmor: 
-- Example for PostgreSQL
CREATE USER anomalyarmor WITH PASSWORD 'secure-password';
GRANT CONNECT ON DATABASE your_db TO anomalyarmor;
GRANT USAGE ON SCHEMA public TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;

​
Use Descriptive Names

Name your data sources clearly: Good names:
  • Production PostgreSQL
  • Analytics Databricks
  • Staging ClickHouse
Avoid:
  • db1
  • test
  • connection

​
Start with One Environment

Begin with your production database, then expand to staging and development environments once you’re comfortable with the setup.

​
Troubleshooting

  1. Verify hostname and port are correct
  2. Check credentials are valid
  3. Ensure AnomalyArmor IPs are allowlisted
  4. Verify SSL/TLS settings match your database
  1. Verify user has SELECT on information_schema
  2. Check schema filters aren’t excluding everything
  3. Confirm tables exist in the monitored schemas
  1. Check database availability and load
  2. Verify network stability
  3. Consider using a read replica for monitoring

​
Common Questions

​
What databases does AnomalyArmor support today?

PostgreSQL (12+), MySQL (5.7+), SQL Server (2012+, including Azure SQL), Amazon Redshift, Databricks (with Unity Catalog), and ClickHouse (21.8+). RDS, Aurora, Supabase, PlanetScale, Cloud SQL, and Azure Database are all supported via the compatible engine’s connector. Snowflake and BigQuery are in active development.

​
Can I connect a database that’s behind a firewall or in a private VPC?

Yes. Three options: (1) allowlist AnomalyArmor’s static outbound IPs (visible in Settings → Security) in your firewall; (2) VPC peering (Enterprise); (3) AWS PrivateLink (Enterprise). SSH tunnel / bastion host is also supported for PostgreSQL and MySQL when direct connectivity is not possible.

​
Can I monitor multiple databases from one AnomalyArmor workspace?

Yes - most customers do. Connect as many as you need; assets across all connections appear in a unified catalog. Plan limits are on monitored tables, not number of connections.

​
Should I point AnomalyArmor at production or a replica?

Either works. A replica has zero impact on primary workload and is the recommended pattern for production-grade deployments. Freshness reflects replica timestamps, so factor in replication lag when setting SLAs.

​
What happens if my database credentials expire or rotate?

Discovery and monitoring jobs fail and the connection moves to Error status. Update credentials under the connection’s settings and re-test; in-flight jobs will resume on the next scheduled run. Consider using credential managers (AWS Secrets Manager, Vault) and rotating via Enterprise SSO to reduce manual updates.

​
Next Steps

Connect PostgreSQL

Full guide with RDS, Aurora, and Supabase instructions

Run Discovery

Scan your database after connecting