Read-only database user generator
No sign-up. Everything here is built in your browser; nothing is sent, the password included.
Database
What it can read
Limits for an AI agent
1. Create the user
Run as an administrator.
-- PostgreSQL. Run as a superuser or the database owner. CREATE ROLE ai_agent_ro LOGIN PASSWORD 'change-me-to-a-long-random-password'; GRANT CONNECT ON DATABASE your_db TO ai_agent_ro; GRANT USAGE ON SCHEMA public TO ai_agent_ro; -- PostgreSQL 14 and older only: every role may create tables in public, -- this one included. Uncomment to revoke that (the default from 15 on). -- It applies to every role, so make sure the app's role owns the schema -- or has its own CREATE grant first. -- REVOKE CREATE ON SCHEMA public FROM PUBLIC; GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_ro; -- Tables created later. This covers tables created by the role running -- this script; add FOR ROLE <owner> if another role creates them. ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_agent_ro; -- Limits for an AI agent. ALTER ROLE ai_agent_ro SET default_transaction_read_only = on; ALTER ROLE ai_agent_ro SET statement_timeout = '30s'; ALTER ROLE ai_agent_ro CONNECTION LIMIT 5;
2. Prove it is read-only
Connect as ai_agent_ro, then:
-- Connect as ai_agent_ro, then: SELECT * FROM public.your_table LIMIT 1; -- works CREATE TABLE public.ro_probe (id int); -- ERROR: cannot execute CREATE TABLE in a read-only transaction DELETE FROM public.your_table; -- ERROR: cannot execute DELETE in a read-only transaction
- The grants are what make the role read-only. default_transaction_read_only is a second layer: a session can switch it off, so never rely on it alone.
- On PostgreSQL 14 and older, any role can create tables in the public schema unless CREATE was revoked from PUBLIC. The commented REVOKE line does that.
- GRANT SELECT ON ALL TABLES covers the tables that exist now. ALTER DEFAULT PRIVILEGES is what covers the ones created later.
Questions
How do I create a read-only user in PostgreSQL?
Create a role that can log in, grant it CONNECT on the database and USAGE on the schema, then GRANT SELECT ON ALL TABLES IN SCHEMA. That covers the tables that exist today; ALTER DEFAULT PRIVILEGES covers the ones created later. On PostgreSQL 14 and older, also revoke CREATE on the public schema from PUBLIC, or the new role can still create tables there.
Is a read-only user enough for an AI agent?
It stops writes. It does not stop the agent from reading every email address, card number and salary the user can select, and the database does not record which question caused which read. Give the agent the narrowest table list you can, the limits on this page, and something in front of the database that masks sensitive columns and logs every request.
Were these commands actually tested?
Yes. Every combination this page can produce — each engine, every table or only some, limits on or off — was run against PostgreSQL 16 and 11, MySQL 8.4, MariaDB 11.8, SQL Server 2022, Oracle 23ai and MongoDB 7. For each one we created the user, connected as it, and confirmed that a read works, that INSERT, CREATE TABLE and DELETE are refused with the error the page shows, that a table left off the list cannot be read, and that the limits are in force.
Why are the commands so different on each database?
Because the permission models are. SQL Server needs a server login and a database user. In Oracle a user is a schema, and it cannot connect at all until it is granted a session. MySQL users belong to a host. MongoDB roles do nothing unless access control is switched on.
Does the password leave my browser?
No. It is generated and the commands are put together in your browser; nothing on this page is sent to a server. Copy the commands, or type your own password.
Read-only stops writes. It does not stop reading every email address.
The Data Console sits on top of this user: sensitive columns are detected and masked before rows leave the server, unmasking is granted per column to named people, and every access is logged.