Database Connections

Let Your Agents Query the Database,
Read-Only Until You Say Otherwise

AgentsRoom manages your MySQL, PostgreSQL, SQL Server, MongoDB, SQLite and Google BigQuery connections and gives your AI coding agents a way to run queries against them. Read-only by default, one statement at a time, with the password kept out of reach.

An agent that can read the real rows stops guessing about your data. An agent that cannot write to them stops being a risk you have to supervise line by line.

Download AgentsRoomFreeSee how it works

Database client

Read-only

AgentsRoom

SELECT id, email, plan FROM users LIMIT 50

DELETE FROM users WHERE id = 42

Blocked : connection is read-only

SSH tunnelbastion.acme.dev

Private subnet

Capped result set

Through your saved connection

One statement per callPassword never leaves the app

How AgentsRoom reaches a database in a private subnet and answers a read-only query from an AI agent.

An AI coding agent that cannot see your data writes code against the schema it imagined. It invents a column, assumes an enum has three values when it has seven, and explains a bug with a theory instead of a row. Giving it a database connection fixes that, and it is also the fastest way to turn a helpful agent into an incident. AgentsRoom is built around that tension.

You save your connections in the app the way you would in any database client : engine, host, port, user, database, and TLS when the server expects it. If the database is not reachable from the open internet, the connection is routed through an SSH tunnel or an AWS SSM port-forwarding session, using the SSH and SSM connections you already saved in AgentsRoom. That is how a database sitting in a private subnet becomes something you can query without opening it to the world.

Every connection starts read-only. A SELECT runs. A statement that would modify data does not, until you have made that specific connection writable and confirmed the operation. Only one statement is accepted per call, so nothing extra hides behind a semicolon, and result sets are capped so a wide query cannot flood an agent or a window. A connection can also be flagged as production, which makes the confirmation harder to give by accident.

Reading is not the whole job. A connection saved on one machine shows up on your others, so you set a database up once instead of once per computer. And a database can be exported to a file, restored from one, or copied straight onto another server, through the same tunnels: the operations you used to leave the app for.

A Database Client That Assumes an Agent Is Driving

MySQL, PostgreSQL, SQL Server, MongoDB, SQLite and Google BigQuery, the server engines reachable in private networks, with the guardrails on by default.

MySQL, PostgreSQL, SQL Server and MongoDB Connections

Save a connection per database : host, port, user, the database to open and TLS when the server requires it. Your local database, the staging one and the production replica all live in the same list, ready to be picked instead of retyped.

Reach a Private Database

A database in a private subnet is not a special case. Route the connection through an SSH tunnel or an AWS SSM port-forwarding session and AgentsRoom opens it for you, reusing the SSH and SSM connections you already saved in the app. A Google Cloud SQL instance is reached by its connection name through the Cloud SQL Auth Proxy, with your own gcloud login and nothing stored.

Read-Only by Default

A new connection can read and nothing else. Queries return rows, statements that would change data are refused. Nobody has to remember to set the safe mode, because the safe mode is where every connection starts.

Two Locks Before a Write

Writing takes two deliberate acts, not one. The connection has to be made writable, and the operation itself has to be confirmed explicitly. A single careless click cannot chain into an UPDATE without a WHERE clause.

One Statement per Call

Each call carries exactly one statement. Anything stacked behind a semicolon is refused rather than executed, so a read that looks like a read cannot smuggle a second statement along with it. Result sets are capped on top of that.

Production Is Flagged

Mark a connection as production and the confirmation gets harder. The database that matters stops looking exactly like the local copy, both to you at the end of a long day and to an agent working through a task list.

Your Connections, on Every Machine

A connection saved on the office machine is there on the laptop: name, host, port, user, default database and the tunnel it goes through. The password is the one thing that stays behind, encrypted on the machine where you typed it, so each machine asks you for it once.

Export, Import, Copy

Dump a database to a .sql file, replay one into a database, or copy one database straight onto another. The target is backed up before it is overwritten, and replacing it outright is a separate, confirmed decision.

Agents Query the Database, They Never Hold the Password

Your database credentials are stored by AgentsRoom, not handed out. An agent asks to run a query against a connection it knows by name, the app opens the connection, runs the statement and returns the rows. The password is never part of what the agent receives, never part of the query it writes, and never part of the conversation it keeps.

The read-only rule is the second half of that, and for an agent it is not something it could talk its way out of. The tool an agent queries with refuses anything but a read unless two things are true: the connection is writable, and you turned on Allow agents to write for that connection. The option is off by default, and the check runs in the desktop app rather than in the agent's process. Your own writes in the console still ask for an explicit confirmation, deliberately harder to give when the connection is flagged as production. Once a connection is open to agent writes, they run without that confirmation, so keep the option for a database you would trust the agent with. Everywhere else, the worst outcome of a bad query stays a wrong answer rather than a lost table.

The single-statement rule closes the classic gap. A call that carries one statement cannot be extended with a semicolon and a second one, so a query that reads as harmless in a review cannot do something else at execution time. SQL Server does not need that semicolon, so there a read is a SELECT or a WITH with no write or transaction keyword anywhere in it, and it runs inside a transaction that is always rolled back. Combined with capped result sets, a mistake stays a mistake instead of becoming an export.

Engine coverage

Six engines, and we name the ones that are missing

MySQL and MariaDB, PostgreSQL, SQL Server (Azure SQL and Amazon RDS for SQL Server included), MongoDB, SQLite and Google BigQuery. Each one has its own driver rather than a translation layer, because they genuinely differ : a PostgreSQL or SQL Server session binds to a single database, MongoDB takes a query rather than SQL, T-SQL does not need a semicolon between two statements, each export runs the tools that engine ships with, SQLite is simply a file on your computer, with no host, user or password, and a BigQuery connection is a Google Cloud project and a default dataset, signed in with your own Google login (gcloud auth application-default login), with no key stored. The four server engines are reached directly, or through an SSH tunnel or an AWS SSM port-forwarding session when they are not exposed to the open internet.

Oracle, Redis and the others are not supported. On SQL Server, you sign in with a SQL login (Windows, Active Directory and Entra ID authentication are not offered), and there is no export, import or copy. On BigQuery, Google bills every query on the bytes it reads, so each connection has a per-query billing cap (1 GiB by default, adjustable): a query above it is refused instead of charged. Opening a table is free and read-only, your agents use the same db_list, db_schema and db_query tools with the same guardrails and see the bytes each query read, and there is no export, import or copy there either. You deserve to know that before the download rather than after it. Which engine comes next is decided by what people ask for, so if yours is missing, say which one on the public backlog and it gets counted.

Request your database engine

Export, import, copy

Move a database, not just read it

Export a database to a file. Import a file into a database. Or copy one database straight onto another, including through the SSH tunnel or the AWS SSM session you already saved. Each engine runs its own official tools, streamed to disk, so a multi-gigabyte database is a progress bar rather than a crash.

Those tools ship with the database, not with AgentsRoom : mysqldump and mysql, pg_dump and psql, mongodump and mongorestore. SQL Server has no equivalent that streams a whole database, so its connections have no export, import or copy. When the tools are missing, the app says exactly which ones and lets you point at the folder holding them, the way a database client should: launched from the Dock or the Start menu, an app sees a bare PATH and would otherwise claim they are missing on a machine that has them.

Copying is where a wrong click costs a day, so it is built around that rather than around the happy path.

A read-only connection refuses the import outright, before anything is opened.
The target is dumped to a file you choose before a single statement is applied.
The confirmation names the connection and the database, and says louder when the connection is flagged as production.
Dropping and recreating the target is a separate option, and on a production connection you have to type the database name.

From a Private Database to an Answer

Save the connection, route it, then query it or let an agent do it.

Save the connection

Add the database : host, port, user, the database name, and TLS if the server expects it. Give it a name you will recognise later, and flag it as production if that is what it is.

Route it if it is private

If the database is not reachable directly, point the connection at an SSH tunnel or an AWS SSM port-forwarding session built from the connections already saved in AgentsRoom. A database in a private subnet becomes reachable without exposing it publicly. On Google Cloud, pick the Cloud SQL instance instead: AgentsRoom starts the Cloud SQL Auth Proxy for you.

Query it, or let an agent query it

Run your statement from the app, or let an agent run one over MCP. Read-only until you change it, one statement per call, capped result sets, and an explicit confirmation standing between any write and your data.

When an Agent Needs the Real Rows

The moments where reading production data is the shortest path to the fix.

Debug against real data

The bug only shows for a handful of accounts. Let the agent read those rows and it finds the value that breaks the logic, instead of proposing three theories about what the data might look like.

A database that is not public

The database lives in a private subnet with no public endpoint. Route the connection through an SSH tunnel or an AWS SSM session built on your saved connections, and query it without opening a port to the internet.

Let the agent check, not guess

Before it writes a migration or a query, an agent can look at what is actually stored. It reads, it reports, and unless you opened that connection to agent writes, it has no way to change anything while it does.

Production, without the write risk

Reading production is often necessary, writing to it almost never is in the middle of a task. Flag the connection as production, keep it read-only, and the difference between investigating and breaking stops depending on anyone paying attention.

Refresh staging from real data

The bug only reproduces on real rows. Copy the database onto your staging server, through the tunnel you already saved, with a dump of what was there taken first.

Open the laptop, everything is there

Your connections follow your account: same hosts, same tunnels, same read-only and production flags. With synced passwords on, the passwords follow too, end-to-end encrypted, so nothing is retyped; without it, each machine asks for the password once.

AI agents + SQL

How do my agents query the database?

db_listdb_schemadb_querydb_connection_new

Through AgentsRoom MCP, with four tools. db_list returns your saved connections and their metadata, db_schema walks the schemas, the tables and the columns without a line of SQL, db_query runs one statement and returns the rows, and db_connection_new proposes a database you have not saved yet. AgentsRoom opens the connection, including the SSH tunnel or the AWS SSM session in front of it when there is one. What travels back to the agent is a result set, never a credential.

Agents can write only when you enable Allow agents to write on a connection that is also writable. This opt-in is off by default and syncs with the connection across your account. Once enabled, writes run immediately, so use it only when you trust the agent with that database. The desktop checks the permission in its main process, and db_query still accepts only one statement per call.

Registering a database can also be entirely the agent's job. db_connection_new keeps the reviewed path: it opens the creation form pre-filled with the host, the user and the SSH or AWS SSM connection it should be reached through, and you review it, type the password and save, nothing being stored until you do. Unless you turn off "Agents can manage connections" (Settings, on by default), db_connection_save writes the connection outright, and the password still never travels through the conversation: it is copied from a vault secret the agent only names. The agent gets what it needs to reason about your data, and none of the ways that access usually turns into an incident are available to it.

Every query an agent runs is visible too. db_query and db_schema calls land in the Activity tab of the right panel, with the SQL and the first rows returned, in one journal per database; the agent's avatar shows on the Databases button and, with an Agent at work badge, in your Databases list. You can also follow it from your phone, in the agent's card of the mobile app. That journal only travels between your computer and your phone, end-to-end encrypted with secrets masked: no result set is stored on a server.

Discover AgentsRoom MCP

The same Activity tab that lists your db_query and db_schema calls, filmed here on a saved SSH server : an agent runs three commands, each one lands with its output, its exit code and its duration, then the journal of that connection opens in full. The journal stays on your computer.

Watch on YouTube

FAQ

Ask us something else

Which databases are supported?

MySQL and MariaDB, PostgreSQL, SQL Server (with Azure SQL and Amazon RDS for SQL Server), MongoDB, SQLite and Google BigQuery. Each has its own driver. The server engines are reachable directly or through an SSH tunnel or an AWS SSM port-forwarding session; a SQLite connection is a file on your computer that you pick by its path; a BigQuery connection is a Google Cloud project, opened with your own Google login and a per-query billing cap (1 GiB by default) so that an expensive query is refused instead of billed. Oracle, Redis and the rest are not supported today. If you need one of them, ask for it on the public backlog : the list grows with what people actually request.

Can an AI agent write to my database?

Yes, when you explicitly allow it. An agent can write only when the connection is writable and you turn on Allow agents to write in that connection's settings. Writes then run immediately, so enable this only when you trust the agent with that database. Otherwise db_query remains read-only.

How do I reach a database in a private subnet?

Route the connection through an SSH tunnel or an AWS SSM port-forwarding session, built from the SSH and SSM connections you already saved in AgentsRoom. The app opens the tunnel or the session and connects the database through it, so the database stays unreachable from the public internet. For Google Cloud SQL, choose the instance (project:region:instance) and AgentsRoom runs the Cloud SQL Auth Proxy with your own gcloud login, over a private IP if needed and with IAM database authentication if you want no password at all.

Do my agents see the database password?

No. Agents query through MCP by naming a connection. AgentsRoom holds the credentials and runs the statement itself, so the password is never returned to the agent, never written into the query and never part of the conversation.

Can an agent run several statements at once?

No. One call carries exactly one statement. Anything stacked behind a semicolon is refused rather than executed, which removes the oldest way to hide a write inside something that looks like a read.

What does flagging a connection as production change?

It hardens the confirmation required before a write. The database that matters stops behaving like the local copy, which is what you want at the end of a long day and what you want even more from an agent working through a task list.

What happens with a query that returns a lot of rows?

Result sets are capped. A query that would return an enormous table comes back truncated instead of flooding the window or the agent context, so a wide SELECT stays an inconvenience rather than an export of your data.

Can an agent add a database connection?

Yes, and by default it can even save it on its own. db_connection_save writes the connection outright, with no form, and the password never appears in a conversation: the agent names a secret from your vault and AgentsRoom copies it into the keychain. Prefer db_connection_new when you would rather review first: it opens the creation form pre-filled with the host, the port, the user and the SSH or AWS SSM connection the database should be reached through, and nothing is stored until you review it, type the password and save, the agent never supplying a credential. Turn off "Agents can manage connections" in Settings and only the reviewed path remains.

How does an agent learn my schema?

With db_schema, which explores a saved connection without any SQL. Called with no argument it lists the schemas, with a database it lists the tables and views, with a table it returns the columns, their types, their nullability, their keys and their defaults. It is cheaper and safer than making an agent query information_schema by hand.

Are my database connections synced between my machines?

Yes. Name, host, port, user, default database, scope, the read-only and production flags and the SSH or SSM tunnel it goes through follow your account, so a connection saved on one machine appears on the others instead of being retyped. By default the password stays encrypted in the keychain of the machine where you typed it, so a connection that arrives from another machine asks for it once. Turn on synced passwords in Settings > Account and the password follows too, end-to-end encrypted with a key only your computers hold: AgentsRoom stores it without being able to read it, and a password you change on one machine is updated on the others. You can still keep any password on one machine only.

Can I dump a database and import it somewhere else?

Yes, on MySQL, PostgreSQL and MongoDB. You can export a database to a file, import such a file back into a database, or copy one database directly onto another, including through the SSH or SSM tunnels you already saved. Each engine runs its own official tools (mysqldump and mysql, pg_dump and psql, mongodump and mongorestore), which ship with the database rather than with AgentsRoom: if they are not found, the app asks you to point at the folder holding them. A copy only runs between two connections of the same engine, since a dump only restores into the engine that produced it. Importing is refused on a read-only connection, the target is dumped to a file of your choosing before anything is written to it, and replacing the target is a separate option that names the database in its confirmation. SQLite has none of this: the database already is a file, which you copy like any other. SQL Server has none of it either: no Microsoft tool streams a whole database the way mysqldump does (sqlpackage writes a .bacpac file, bcp copies one table at a time).

How is the account that holds my connections protected?

Passwords stay in your system keychain, and the account that carries your connections to your other computers can ask for a second proof at sign-in. Turn on two-factor authentication in Settings, Account: a 6-digit code from an authenticator app on your phone is then asked at every password sign-in, on the desktop, the phone and the site, and you get 10 single-use recovery codes in case you lose the phone. A stolen password alone is no longer enough to open the account.

Screenshots

Real captures of the app, added as this feature evolves.

Connect Google BigQuery with your own Google login
Cap what one BigQuery query may bill, per connection
Direct TLS connections verify the server certificate, with an opt-in for self-signed servers

1 / 3

Give Your Agents the Data, Not the Keys

Download AgentsRoom, save your MySQL, PostgreSQL, SQL Server, MongoDB, SQLite and Google BigQuery connections, reach the server ones through an SSH tunnel or an AWS SSM session, and let your agents query them, read-only unless you open a connection to their writes.

DownloadFree

Companion app: monitor your agents on the go

Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.

Get the extension

Chrome Web Store

Push bugs and requests straight to your public backlog.

Agents you read like a conversation

Each agent has a role, a face, and a thread you read like a messaging app.

Conversation view

Multiple projects

Multi-provider

Multiple agents

Live status

File diff & commit

Mobile companion

Live preview

Agent teams

Browser automation

Backlog-driven dev

Prompt Library

Skills Library

View all features

Let Your Agents Query the Database,
Read-Only Until You Say Otherwise

A Database Client That Assumes an Agent Is Driving