Privacy and data handling
What RDST stores on your machine, what it sends to an LLM and when, what it never sends, and how to turn off usage telemetry.
RDST runs on your machine and connects directly to your database. There is no RDST account, no server holding your data, and nothing is uploaded for RDST to work.
This page covers exactly what is stored, what leaves your machine, and how to turn off the parts you do not want.
What RDST stores
Everything lives in ~/.rdst on your own disk.
| File or directory | Contents |
|---|---|
config.toml | Connection details for your targets: host, port, database, user |
queries.toml | The query registry: query text, hashes, and timings |
semantic-layer/ | Table and column descriptions you or RDST wrote |
audits/ | Saved health reports |
conversations/ | Follow-up question threads from Analyze |
device_id, stats.json | An anonymous identifier and cumulative usage counts |
Remove all local data in Settings deletes the directory and everything in it.
Database passwords are never stored
config.toml records how to reach a database, never how to authenticate to one.
Passwords go into your operating system keyring: Keychain on macOS, Credential
Manager on Windows, the Secret Service on Linux. Where a password comes from an
environment variable, the file records the variable's name and never its value.
This is what makes config.toml safe to commit to a dotfiles repository or hand
to a colleague.
On a system with no keyring available, RDST holds passwords in memory for the session only. Nothing is written to disk, and each target asks for its password again next time you start the app.
What is sent to an LLM
Only the features that need reasoning call an LLM, and only when you use them: Analyze Query, Ask, schema discovery, and the written sections of a health report. Everything else in the app works without any LLM contact at all.
| Sent | Not sent |
|---|---|
| Query text, with literal values already replaced by placeholders | The rows your queries return |
Execution plans from EXPLAIN and EXPLAIN ANALYZE | The contents of your tables |
| Schema metadata: table names, column names and types | Your database credentials |
| Descriptions you wrote in the semantic layer | Your connection details |
The distinction that matters most: RDST sends the shape of your workload, not your data. A health check reports that a table holds 1.5 million rows without sending any of them, and Analyze sends a query's plan rather than its results.
Query text arrives parameterized, because that is how your database stores query
statistics. WHERE customer_id = 88213 reaches the LLM as WHERE customer_id = $1, so the values your application passed are not part of the request.
Requests go to Anthropic, using your key or your trial balance.
What is sent to Readyset
Your database contents and queries are never sent to Readyset.
When you run a comparison or the demo, Readyset runs as a container on your machine. It connects to your database locally to serve cached results, and the data stays between those two processes. Nothing is transmitted to Readyset the company, and the containers are removed when you are done with them.
Usage telemetry
RDST reports anonymous usage telemetry so we can see which features are used and where they fail. This is the one thing that does leave your machine on its own.
| Collected | Never collected |
|---|---|
| A random device identifier | Your name, email, or IP-derived identity |
| RDST version, operating system, Python version | Query text |
| Which commands ran, and whether they succeeded | Table, column, or database names |
| Query hashes, so repeat analyses can be counted | Connection details or credentials |
| Cumulative counts of how often features are used | Anything your queries returned |
Queries appear only as hashes. The hash identifies that the same query was analyzed twice; it cannot be turned back into the query.
Turning it off
Set an environment variable:
export RDST_TELEMETRY=offOr add a line to ~/.rdst/config.toml:
telemetry_enabled = falseEither one disables it completely, and nothing else in RDST changes.
Working in a restricted environment
For a database that nothing outside its network may reach, run RDST next to it.
Install the CLI on a host inside the perimeter and use
rdst web over SSH port forwarding,
which puts this same interface in your browser while the database connection
stays inside the network.
Without an LLM key configured, RDST makes no outbound requests other than telemetry, which the setting above disables.