Chat With Your PostgreSQL Database

What it reads when it connects

On first connection SQLore introspects the Postgres catalog directly rather than relying on a generic description of your database. It reads across every schema on the search path, not just `public`, which is the detail that decides whether a question about a table in `analytics` or `billing` can be answered at all.

• Tables, views and materialised views, with their owning schema.
• Columns and their Postgres types — including `jsonb`, arrays, enums and domains.
• Primary and foreign keys, which become the join paths it is allowed to use.
• Distinct values on low-cardinality columns, so a filter on a status matches what is stored.
• Planner statistics, so it has a sense of table size before it writes a join.

Conversation, not one-shot queries

The first question is rarely the real one. You ask for signups by month, see the shape, and then want it split by plan, excluding internal accounts, for the last two quarters only. Each of those is a follow-up rather than a new query written from scratch — the conversation keeps the tables, the joins and the filters it has already established, so you refine an answer instead of re-specifying it.

Read-only, enforced twice

Generated SQL is parsed to an AST and validated down to a single read-only SELECT before execution, then run on a read-only connection with a statement timeout. On top of that, pointing SQLore at a Postgres role with only `SELECT` granted — or at a read replica — means the guarantee is enforced by your database as well as by the application. Two independent mechanisms, because one of them is ours and you have no reason to take our word for it.

When the schema changes

Migrations happen, and a cached schema that has gone stale is how an assistant starts referencing a column that was dropped last week. Refreshing a connection re-reads the catalog and rebuilds the index. Nothing is ever written back to your database in the process — the introspection is entirely reads against the catalog.