Security and Access Control

Last updated August 18, 2026 · By the SaturnSQL team

Giving a tool access to your production database is a real decision, so this page describes what SaturnSQL actually does rather than how seriously it takes security. It also states plainly what is not built yet, because finding that out during procurement is worse than reading it here.

Who can do what

Every person in a company holds one of three roles. Admins manage users, connections and billing. Members write and run SQL against the connections shared with them. Viewers see shared dashboards and nothing else: no SQL editor, no schema, no connection details. That last role exists so you can hand a report to someone in finance or support without handing them database access at all. It is described in full under the viewer role.

Roles are checked on the server on every request, not hidden in the interface, and a role change takes effect on the person's next action rather than their next sign-in.

Your database credentials

Connection credentials are encrypted with AES-256 before they are stored, using a key that lives in the application environment rather than alongside the data. They are never sent back to the browser. The editor sends SQL to the server and receives rows; the host, user and password stay server-side for the lifetime of the connection.

The practical consequence is that someone who compromised a SaturnSQL account would get whatever that account can query, but would not walk away with your database passwords.

Limiting what SaturnSQL can do to your database

Two controls, and they work best together. Each connection has a read-only switch that rejects INSERT, UPDATE and DELETE before they leave us. Stronger than that is connecting with a read-only database user, because then your database enforces the limit itself and no bug or setting on our side can widen it. For anything touching production, do both.

Result sets are also capped, so an accidental unbounded SELECT cannot pull an entire table through the connection. See row limits.

Network access

You do not have to open your database to the internet.

• Static egress IP. Enable it per connection and SaturnSQL reaches your database from 100.49.19.161, so your firewall can allow one address. See the static IP guide.
• SSH bastion. For databases with no public endpoint at all, connections can be tunnelled through an SSH host inside your network. See connecting through an SSH bastion.
• TLS, including private certificate authorities. Connections use TLS, and you can pin your own CA certificate for databases that present an internal or self-signed certificate. See SSL certificates.

Account security

• Passwords are hashed with bcrypt. Google sign-in is available and avoids a password entirely.
• Two-factor authentication using any TOTP app, enrolled per person from Settings → Profile.
• Sessions use a 24-hour token with a longer-lived refresh token, so a stolen session token ages out on its own.
• API keys are scoped and revocable. A sat_live_ key carries only the scopes you grant it, out of read, execute and write, and it can never manage other keys, users, billing or connections. Keys are stored as SHA-256 hashes, so the plaintext is shown once at creation and cannot be recovered afterwards. Give an agent the narrowest scope it needs, name the key after it, and set an expiry. See the API reference.

What SaturnSQL does not have

Stated so nobody discovers it late in an evaluation:

• No SAML single sign-on and no SCIM provisioning. Sign-in is email and password or Google, with optional TOTP. If SSO is a hard requirement, SaturnSQL does not meet it today.
• No self-hosted option. SaturnSQL is cloud-only.
• No SOC 2 or ISO 27001 report. We are a small team and have not been through either audit.

Data protection and contracts

The Data Processing Agreement covers GDPR Article 28 processor terms, including subprocessors, security measures and international transfers. Which subprocessors we use, and what we store about you rather than about your data, is in the privacy policy.

Reporting a vulnerability

Use the contact form on our help page and include enough detail to reproduce the issue. We will acknowledge it, and we will not pursue anyone who reports a genuine finding in good faith without accessing other people's data.