When setting up a database connection for an external tool, there is always a tempting shortcut: use the root user, the superuser, or the application’s own database user. It already exists. The password is already somewhere in the codebase. It works immediately.
This is one of the most common misconfigurations in software teams, and it’s worth understanding why it matters.
What “root user” means in practice
Different databases name their superuser differently, but the concept is the same:
- PostgreSQL: The
postgresuser (or any user withSUPERUSERattribute) - MySQL: The
rootuser (or any user withALL PRIVILEGES ON *.*)
A superuser can do everything: read data, write data, drop tables, drop entire databases, create new users, read any table in any schema, and bypass row-level security policies. There is no guard rail.
The principle of least privilege
Least privilege is a security principle with a simple formulation: every user, process, and system should have access to exactly what it needs to do its job — and nothing more.
Applied to database users: a tool that only needs to read data should connect with a user that can only read data. It should not connect with a user that can also write, drop, or modify.
This is not primarily about preventing external attackers. It is about containing the consequences of anything going wrong.
What “going wrong” looks like
Scenario 1: Credential theft
A developer’s laptop is compromised. An attacker finds the credentials stored in a .env file or in the tool’s settings.
- With a superuser: the attacker has full access to every table, can exfiltrate the entire database, modify any record, and create backdoor accounts.
- With a read-only user: the attacker can only read the tables the user had access to. They cannot modify data, create users, or escalate privileges within the database.
Scenario 2: Misconfigured query
A team member writes a natural language prompt that gets translated into a query with an unintended side effect — a DELETE without a WHERE clause, an UPDATE that hits every row.
- With a superuser: the query executes. Data is gone or corrupted.
- With a read-only user: the query is rejected by the database. No data is affected.
Scenario 3: Vendor breach
The external tool’s infrastructure is compromised. Encrypted credentials are exfiltrated. The encryption is eventually broken (or there was a vulnerability in the credential storage).
- With a superuser: the attacker now has full database control.
- With a read-only user: they can read data but not modify it. Combined with table-level restrictions, they may only access a subset of your data.
The blast radius is what matters, not the probability
Security decisions are often framed as: “What is the probability this gets exploited?” That is the wrong question.
The right question is: “If something goes wrong, what is the maximum damage?”
With a root user, the maximum damage is total: every byte of data can be read, every table can be dropped, every record can be changed. With a read-only user scoped to a specific schema, the maximum damage is bounded.
You can’t control whether a breach happens. You can control how much it costs if it does.
The effort is minimal
Creating a read-only user takes about two minutes. The guides in this documentation cover the exact steps for PostgreSQL and MySQL.
The inconvenience is tiny. The protection is real.
One exception worth knowing about
If a tool needs to create tables, manage migrations, or write data as part of its core function (e.g., a replication tool or a backup agent), it genuinely needs more than read-only access. In that case, create a user with the minimum additional permissions that specific function requires — not a superuser.
Read-query tools — analytics platforms, BI tools, query assistants — have no legitimate need for anything beyond SELECT. If a tool asks you to connect with admin credentials, that is a signal worth examining.
Summary
| Root / Superuser | Read-only user | |
|---|---|---|
| Can read data | Yes | Yes |
| Can write / modify data | Yes | No |
| Can drop tables | Yes | No |
| Can create users | Yes | No |
| Blast radius if compromised | Total | Limited to readable tables |
| Setup time | 0 minutes | ~2 minutes |
Always use a dedicated, least-privilege user for external tool connections. It is the lowest-cost, highest-value security control available.