Skip to main content
Connect AnomalyArmor to any PostgreSQL-compatible database. This guide covers self-hosted PostgreSQL as well as managed services like Amazon RDS, Aurora, and Supabase. PostgreSQL Connection Architecture showing TLS encryption and metadata-only access

Supported Versions & Platforms

Connection Settings

SSL Mode Options

SSL (Secure Sockets Layer) encrypts the connection between AnomalyArmor and your database, preventing eavesdropping on sensitive data like credentials and query results. Why use SSL?
  • Security: Encrypts all data in transit, protecting against network sniffing
  • Compliance: Required for SOC2, HIPAA, PCI-DSS, and other security standards
  • Cloud providers: Most managed databases (RDS, Aurora, Cloud SQL) require or strongly recommend SSL
When SSL may not be needed:
  • Local development databases on localhost
  • Databases on a private network with no external access
  • Testing environments with non-sensitive data

Choosing an SSL Mode

Recommendations by Environment

When in doubt, start with prefer. It provides encryption when available without blocking connections if SSL isn’t configured on your database.
Never use disable for production databases or any database containing sensitive data.

SSH Tunnel (Bastion Host)

For databases behind firewalls, AnomalyArmor supports SSH tunnel connections through a bastion host. This is common in enterprise environments where databases are not directly accessible from the internet.

When to Use SSH Tunnel

  • Database is in a private subnet with no public IP
  • Firewall rules prevent direct connections
  • Security policy requires bastion host access

SSH Tunnel Settings

Enable SSH Tunnel in the connection form to reveal these fields:
  1. Generate an SSH key pair (or use existing):
  2. Add the public key to the bastion host’s ~/.ssh/authorized_keys
  3. In AnomalyArmor, paste the contents of the private key file or click Upload Key File
Key-based authentication is more secure and doesn’t require password rotation.

Password Authentication

If your bastion host uses password authentication:
  1. Set Authentication Method to Password
  2. Enter the SSH password
Key-based authentication is more secure than passwords. Use password auth only if key auth is not available.

Connection Flow with SSH Tunnel

SSH Tunnel Connection Flow
  1. AnomalyArmor connects to your bastion host via SSH
  2. An encrypted tunnel is established to your database
  3. Database traffic flows securely through the tunnel
  4. The tunnel closes automatically after each operation

Creating a Read-Only User

Create a dedicated user with minimal permissions.
Quick Setup: View the PostgreSQL permissions script for a ready-to-use SQL template with all necessary grants.

Verifying Permissions

Test that the user can access metadata:

Provider-Specific Instructions

Amazon RDS PostgreSQL

Connection Details:
  • Host: Your RDS endpoint (e.g., mydb.abc123.us-east-1.rds.amazonaws.com)
  • Port: 5432 (default)
  • SSL Mode: require
Security Group Configuration:
  1. Go to AWS Console → RDS → Your Instance → Security Groups
  2. Edit inbound rules
  3. Add rule:
    • Type: PostgreSQL
    • Port: 5432
    • Source: AnomalyArmor IPs (see Settings → Security)
AWS Security Group RulesParameter Group (if using verify-ca or verify-full):
  • Ensure rds.force_ssl = 1
  • Download RDS CA certificate bundle
RDS instances in private subnets require NAT Gateway or VPC peering for AnomalyArmor access. Contact us for Enterprise VPC peering options.

Connection Pooling Considerations

If you use a connection pooler (PgBouncer, Pgpool):

PgBouncer

  • Transaction mode: Works with AnomalyArmor
  • Session mode: Recommended for best compatibility
  • Statement mode: May have issues with complex queries
Connect directly to PostgreSQL, not through PgBouncer, unless you have connection limit constraints.

Connection Limits

AnomalyArmor uses 1-2 connections during discovery. If you’re near your connection limit:
  1. Use a read replica for monitoring
  2. Schedule discovery during off-peak hours
  3. Increase max_connections if possible

What We Query

AnomalyArmor runs these types of queries:
Impact: Minimal. These are lightweight metadata queries.

Troubleshooting

Causes:
  • Firewall blocking the connection
  • Wrong hostname or port
  • Database not running
Solutions:
  1. Verify AnomalyArmor IPs are allowlisted
  2. Check security group rules (for RDS/Aurora)
  3. Test connectivity: nc -zv hostname 5432
  4. Verify database is accepting connections
Causes:
  • Wrong password
  • User doesn’t exist
  • pg_hba.conf not configured
Solutions:
  1. Verify password (copy-paste to avoid typos)
  2. Confirm user exists: SELECT usename FROM pg_user;
  3. Check pg_hba.conf allows the connection method
  4. Try resetting the password
Causes:
  • Database requires SSL but connection uses disable
  • Wrong SSL mode for the server
Solutions:
  1. Set SSL Mode to require
  2. For RDS/Aurora/Supabase: SSL is required
  3. For self-hosted: Enable SSL or allow non-SSL (not recommended)
Causes:
  • User lacks SELECT permission
  • Schema permission missing
Solutions:
Causes:
  • User can’t see tables in information_schema
  • Schema filter excluding all schemas
Solutions:
  1. Test as the user: SELECT * FROM information_schema.tables LIMIT 5;
  2. Check schema filter settings in AnomalyArmor
  3. Verify tables exist in the expected schemas
Causes:
  • Invalid SSH credentials
  • Bastion host not reachable
  • SSH port blocked
Solutions:
  1. Test SSH connection manually: ssh -i key.pem user@bastion.example.com
  2. Verify SSH host and port are correct
  3. Check that AnomalyArmor IPs can reach the bastion host
  4. Ensure the SSH user has permission to forward connections
Causes:
  • Invalid private key format
  • Wrong passphrase for encrypted key
  • Public key not added to bastion
Solutions:
  1. Verify key is in PEM format (starts with -----BEGIN)
  2. For encrypted keys, ensure passphrase is correct
  3. Check ~/.ssh/authorized_keys on bastion includes your public key
  4. Verify SSH user exists on the bastion host

Common Questions

Which PostgreSQL-compatible services does AnomalyArmor support?

PostgreSQL 12+ self-hosted, Amazon RDS, Amazon Aurora (cluster and serverless), Supabase, Google Cloud SQL, Azure Database for PostgreSQL (single and flexible server), and Heroku Postgres. Any managed PostgreSQL that exposes the wire protocol on a network-reachable port works.

What SSL Mode should I use for RDS or Aurora?

require is the right default - it encrypts traffic without pinning certificates. Use verify-ca or verify-full if your compliance program requires CA validation; you’ll need to upload the RDS/Aurora CA bundle in connection settings. Never use disable for managed cloud databases.

My PostgreSQL is only reachable through a bastion host. Can AnomalyArmor still connect?

Yes. Enable SSH tunnel mode on the connection, provide the bastion’s host, port, user, and an SSH key, and AnomalyArmor tunnels to your PostgreSQL through it. The bastion needs outbound access to your database on port 5432.

Does AnomalyArmor support PostgreSQL logical replication or CDC?

Not for primary monitoring. AnomalyArmor monitors via information_schema and bounded aggregates on a schedule - it does not read the WAL or consume replication slots. For freshness, it uses MAX(timestamp_column), which works without replication.

How do I give AnomalyArmor access to future tables without re-granting permissions?

Use ALTER DEFAULT PRIVILEGES so new tables created in the monitored schema automatically grant SELECT to the AnomalyArmor user:
Run it once per schema you want monitored. Existing tables still need an explicit GRANT SELECT ON ALL TABLES the first time.

Next Steps

Run Discovery

Scan your PostgreSQL database

Set Up Alerts

Get notified of schema changes