Chat with your database
Point Memtro at a read-only replica and anyone can ask a database a question. The agent reads the schema first, writes the query, runs it, and shows you the SQL beside the answer so it can be checked. Queries that worked are remembered, so the next person asking a similar question starts from a query that already ran.
The problem
- The people with questions cannot write SQL, and the people who can are a queue.
- A dashboard answers the question it was built for and none of the follow-ups.
- A generated query that nobody can see is a guess with a confident number on it.
- Every analyst rewrites the same joins because the last correct query lived in somebody's history.
How it works
- Connect Postgres, MySQL, SQL Server, Snowflake, BigQuery, Redshift, ClickHouse or Athena with a read-only role; the connector cannot write, whatever it is asked.
- The agent reads the schema, writes the query, and returns the rows with the SQL that produced them, so a figure can be traced back to its query.
- A query that ran is kept in memory with the tables it touched, and the schema tool hands the ones that worked back before a new one is written.
- A question you keep asking becomes a metric: measured on a schedule, remembered with its provenance, and drawn as a sparkline on the Metrics tab.
- The same answer can draw on the CRM, the support desk and the ledger in one reply, because the database is one connector among many.
Ask it like this
- › How many orders shipped late last month, by warehouse?
- › Which customers' usage dropped more than 30% quarter on quarter?
- › Show me the SQL behind that figure
- › Save weekly active organisations as a metric, measured every Monday
Setting it up
- 01Create a read-only role in the database and grant it select on what Memtro should be able to see. The guide has the exact grants for each engine.
- 02Add the connection under Connections: a connection string, or host and credentials. Postgres, MySQL and SQL Server also take an SSH tunnel, so a database on a private network never needs a public address.
- 03Decide who may use it, tool by tool, on the Permissions page: everyone in the organisation, or named teams.
- 04Ask a question. The agent calls the schema tool first, then writes the query, and shows the SQL beside the rows.
The tools behind it
- The connector's schema toolTables, columns and types — called before any SQL is written, and it hands back the queries that already worked over those tables.
- The connector's query toolRuns the statement read-only and returns the rows with the SQL that produced them.
- memtro_searchFinds the query that answered a similar question last time, as an ordinary fact with its provenance.
Available wherever Memtro answers: the Chat page, the API and any MCP client. Every input is in the tools reference.
What it does not do
- It cannot write. The role is read-only, the connector's tools only read, and every query runs in a read-only transaction with a statement timeout and a row cap.
- It answers from the data rather than from your BI tool's definitions. A figure a dashboard computes differently will differ — and the SQL is shown, so you can see which of you is counting what.
- A question the schema cannot answer comes back saying so, rather than producing a plausible number from the wrong table.
- Remembered queries are a hint, not a cache. Every question is answered by running SQL now; what is remembered is which joins turned out to be right.
Questions
Can it change anything in the database?+
No. The connection uses a read-only role you create, and the connector's tools only read. The guide shows the exact grants for each database.
Do I have to trust the number?+
The SQL is shown beside every answer and the rows come from your own database, so the query can be checked by anyone who can read SQL, and the figure cites the query that produced it.
Which databases are supported?+
Postgres, MySQL, SQL Server, Snowflake, BigQuery, Amazon Redshift, ClickHouse, AWS Athena and MongoDB, plus analytics tools such as Metabase and Grafana.
Can it reach a database on a private network?+
Yes. Postgres, MySQL and SQL Server connections take an optional SSH tunnel: give Memtro a bastion host and a key or password and each query is forwarded through it, so the database never needs a public address.
Who can query it?+
Whoever you grant, tool by tool. A shared connection can be open to the organisation or restricted to named teams, and the grant holds in chat, the API, jobs, MCP and the sandboxed engines alike.
What stops a runaway query?+
Every statement runs in a read-only transaction with a statement timeout and a cap on rows returned, so a question that would table-scan your warehouse fails quickly rather than expensively.
Other things it does
- A decision log that writes itselfThe reasons behind the code, read from pull requests and threads, kept against the code, and posted back when you ask.
- Action items that get checked, not just listedWho promised what, by when, read from meetings and chat, then checked against the systems where the work would show up.