Readyset Docs

Minimum PostgreSQL and MySQL privileges for RDST, optional monitoring access, and the additional permissions used by Readyset caching.

RDST CLI should connect with a dedicated read-only database user. Most features need permission to connect, inspect the schema, and read the application tables you want RDST to analyze. Live and historical workload monitoring need additional access to server-wide statistics.

RDST does not run these GRANT statements for you. Ask a database administrator to create the user, replace the example names, and limit it to the databases and schemas you want RDST to inspect.

Permissions by feature

Feature	PostgreSQL	MySQL
Connect and test credentials	`CONNECT` on the database	Permission to connect to the server
Schema, Analyze, Ask, and query execution	`USAGE` on each schema and `SELECT` on the relevant tables and views	`SELECT` on the relevant database; `SHOW VIEW` when inspecting or explaining views
Realtime monitoring of this user's sessions	Baseline access	Baseline access
Realtime monitoring of all sessions	Membership in `pg_read_all_stats`	Global `PROCESS`
Historical slow queries	`pg_stat_statements` enabled, plus `pg_read_all_stats` to see other users' query text	`performance_schema` enabled and `SELECT` on `performance_schema.*`
Health Check	Baseline access gives partial results; `pg_monitor` provides the most complete server-wide view	Baseline access gives partial results; `PROCESS`, Performance Schema access, and `REPLICATION CLIENT` provide more complete results
RDST cache deploy and compare	Baseline query-read access; current RDST deployments use shallow caching	Baseline query-read access; current RDST deployments use shallow caching
Deep Readyset caching	Replication and database-administration setup described in the Readyset Cache guides	Snapshot and replication setup described in the Readyset Cache guides

Optional monitoring privileges expose query text and activity from other database users. If you omit them, RDST can still connect and analyze queries, but TOP and Health Check may show only RDST's own sessions or incomplete historical statistics. Some checks degrade to partial or empty results rather than returning an explicit permission error.

Create a read-only user

Run the following as an administrator. Replace my_database, public, and app_owner with the database, schema, and role that owns your application tables.

CREATE ROLE rdst_readonly
  LOGIN
  PASSWORD 'replace_with_a_strong_password'
  NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION NOBYPASSRLS;

GRANT CONNECT ON DATABASE my_database TO rdst_readonly;

-- Run the remaining statements while connected to my_database.
GRANT USAGE ON SCHEMA public TO rdst_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO rdst_readonly;

-- Keep access when app_owner creates new tables in this schema.
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA public
  GRANT SELECT ON TABLES TO rdst_readonly;

Repeat the schema grants for every application schema RDST should inspect. ALTER DEFAULT PRIVILEGES affects only objects subsequently created by the named owner, so repeat it for each role that creates tables.

For complete workload monitoring, add the predefined statistics role:

GRANT pg_read_all_stats TO rdst_readonly;

For the most complete Health Check instead, grant pg_monitor, which includes pg_read_all_stats as well as access to additional settings and statistics. You do not need to grant both roles.

GRANT pg_monitor TO rdst_readonly;

A database administrator must also enable pg_stat_statements before RDST can show historical query statistics:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

PostgreSQL may also require pg_stat_statements in shared_preload_libraries, which is a server or managed-service parameter rather than a user privilege.

Run the following as an administrator. Replace my_database and the host pattern with the narrowest values that match the RDST machine.

CREATE USER 'rdst_readonly'@'10.0.0.%'
  IDENTIFIED BY 'replace_with_a_strong_password';

GRANT SELECT ON `my_database`.*
  TO 'rdst_readonly'@'10.0.0.%';

If RDST must inspect or explain views, add:

GRANT SHOW VIEW ON `my_database`.*
  TO 'rdst_readonly'@'10.0.0.%';

For complete realtime and historical monitoring, add:

-- Shows statements run by sessions belonging to other users.
GRANT PROCESS ON *.* TO 'rdst_readonly'@'10.0.0.%';

-- Reads statement digests and other diagnostic statistics.
GRANT SELECT ON performance_schema.*
  TO 'rdst_readonly'@'10.0.0.%';

-- Adds replication status to Health Check.
GRANT REPLICATION CLIENT ON *.*
  TO 'rdst_readonly'@'10.0.0.%';

Performance Schema statement instrumentation and the statements_digest consumer must also be enabled. Those are MySQL server settings; granting SELECT cannot enable collection by itself.

If you explicitly use TOP's MySQL slow-log source, also grant SELECT ON mysql.slow_log and configure the server with slow_query_log=ON and log_output=TABLE.

Verify the account

After creating the user, connect with it and run a target test:

rdst configure test my-target

The test verifies connectivity and reports if RDST detects write privileges. Then exercise the features you intend to use:

rdst schema refresh --target my-target
rdst top --target my-target --duration 10
rdst top --target my-target --historical

An empty or incomplete TOP result does not necessarily mean the database is idle. It can mean the account can see only its own sessions, the statistics extension is unavailable, or statement collection is disabled.

EXPLAIN ANALYZE executes the query while collecting its plan and timing. Keep the account read-only, and use RDST's fast or schema-only analysis when executing a potentially expensive query is not appropriate.

Readyset caching uses different permissions

The grants above are sufficient for RDST's diagnostic, analysis, and current shallow cache-deployment features. A deep Readyset deployment additionally snapshots tables and follows the database replication stream, so it requires broader upstream permissions and server configuration.

Treat those as a separate deployment credential when possible. Do not add replication or administrative privileges to a diagnostics-only RDST user unless you are intentionally using it to deploy deep caching.

Why least privilege matters

RDST applies query-safety checks and uses read-only sessions where configured, but database permissions are the final enforcement boundary. Audit direct, inherited, default, PUBLIC, and routine-execution privileges: a role that has no direct table-write grant may still inherit broader access or invoke a security-definer routine with side effects.

On MySQL, incomplete Performance Schema access can make unavailable index counters look like zeroes, which may cause Health Check to report a false "unused index" finding. Confirm permissions and collection settings before acting on that recommendation.

Database permissions

Permissions by feature

Create a read-only user

Verify the account

Readyset caching uses different permissions

Why least privilege matters

On this page