SaturnSQL's Static IP Address

Last updated August 14, 2026 · By the SaturnSQL team

Add an inbound rule for 100.49.19.161/32 on your database port (5432 PostgreSQL, 3306 MySQL, 1433 SQL Server, 5439 Redshift, 8443 or 8123 ClickHouse), then hit Test Connection in SaturnSQL. There is nothing to enable on our side: every connection already uses this address. BigQuery and DynamoDB go through Google's and AWS's APIs, which authenticate by credentials, so they need no rule.

• AWS RDS / EC2: security group inbound rule, source 100.49.19.161/32.
• Azure: Networking → Firewall rules → 100.49.19.161 as both start and end IP.
• Google Cloud SQL: Connections → Authorized networks → 100.49.19.161/32.
• Self-hosted: sudo ufw allow from 100.49.19.161 to any port 5432 proto tcp.

No public endpoint to open?

A firewall rule only helps a database that has a public endpoint. If yours sits in a private subnet with no route from the internet, connect through an SSH bastion instead: the bastion allows this same static IP on port 22, and the database stays private. For Redshift there is an even lighter option, the Data API, which talks to the cluster over HTTPS with IAM credentials and needs no firewall rule at all.

Two things to know

Every SaturnSQL account uses this same address. The rule says "SaturnSQL may reach this database", not "only my account may", so keep strong credentials and a read-only database user in place too.

Certificates follow each connection's own SSL settings. They are checked against your real hostname exactly as on a direct connection. If you have ticked Allow expired or mismatched certificates, they are not checked, and the static IP does not change that: it controls who can reach your database, not who your database is talking to.