Database access management without shared passwords

Database access management means deciding who can query which database, with what rights, and keeping a record of it. For most teams the hard part is the connection string: once it is shared, you can no longer tell people apart or take access back from one person. SaturnSQL keeps the credentials in one place and gives people, and their AI clients, access to the connection instead of the password.

What shared credentials cost you

• The connection string lives in Slack, a wiki page and a dozen laptops
• The database logs show one shared user, so nobody knows who ran what
• Someone leaves and the password has to be rotated for everyone
• Giving one person read-only access means creating and managing yet another database user
• Every new AI tool asks for the same connection string

Share the connection, not the password

Add a database once in SaturnSQL. The credentials are encrypted with AES-256 and never sent back to the browser. Share the connection with the company or keep it private. Teammates query it from the browser, and nobody copies a connection string onto their laptop. Deleting a connection or un-sharing it stays with its owner. The day-to-day side, with shared queries and schedules, is covered in database collaboration.

Roles decide what each person can do

• Admins manage users, connections and billing.
• Members write and run SQL on the connections shared with them.
• Viewers see shared dashboards and nothing else, so finance or support get the numbers without database access.

Roles are checked on the server on every request, so a role change takes effect on the person's next action.

Read-only where it matters

Each connection has a read-only mode that accepts only single SELECT, WITH or EXPLAIN statements. For production, also connect with a read-only database user so the database enforces the limit itself. Result sets are capped by row limits.

AI clients follow the same rules

Claude, ChatGPT and Cursor connect through SaturnSQL's hosted MCP server, and each person signs in as themselves. The AI sees only the connections shared with that person, under their role, and never the password. On Enterprise, you also set AI access per connection and review every query in the audit log. See database governance for MCP and AI.

Keep the database off the internet

Allow SaturnSQL's static IP 100.49.19.161 in your firewall, tunnel through an SSH bastion for databases without a public endpoint, and pin your own CA for TLS.

Common questions

Do people ever see the database password? No. Whoever adds the connection enters the credentials once. SaturnSQL encrypts them with AES-256 and never sends them back to the browser, so teammates query the database without ever holding the password. A teammate can even rotate the password on a shared connection without seeing the old one.

What happens when someone leaves? Remove them from the workspace. Membership is checked on every request, so their access, including any AI clients they connected, ends on their next call. Because they never had the database password, there is nothing to rotate.

Can I give someone results without SQL access? Yes. The viewer role sees dashboards shared with the company and nothing else: no editor, no schema and no connection details.

Is this a privileged access management (PAM) tool? No. SaturnSQL manages query access to databases through a browser workspace and an MCP server. If you need SSH sessions, admin access to servers or just-in-time access requests with approvals, a PAM product such as StrongDM or Teleport is the right category.

Which databases does it work with? PostgreSQL, MySQL and MariaDB, SQL Server, Oracle, Amazon Redshift, ClickHouse, BigQuery and DynamoDB. Snowflake is available on the Pro plan.

More on how SaturnSQL handles credentials, sessions and network access is on the security page. For a whole-team rollout, see the collaborative SQL editor and sharing SQL queries.