Operational numbers from your reporting database, without waiting on an analyst

The question is small. How many orders did we take last month? The answer is sitting in the reporting database. Between the two is a queue, because the person who can write the query has other work, and the number you wanted for this morning's meeting turns up on Thursday.

With the reporting database connected to GPTree, you can ask that question in ordinary words. Here is one worked example, including the places where GPTree stops and checks with a person.

The setup, done once

Whoever looks after the database creates a database user that can only read, then connects the reporting database in Settings, then Knowledge sources, under "Databases". PostgreSQL, MySQL and MariaDB are supported. GPTree refuses to connect with a user that can change data, and it never changes data in the database.

Connecting a database and asking it questions are included on the Pro and Team plans.

One choice made at setup matters to you later, because it decides who approves a query:

• With "Views only", the default, GPTree reads views, and the person asking approves their own query.
• With "Tables", GPTree reads tables directly, and an admin of the connection approves each query.

The worked example

Say the reporting database holds your orders in an orders table, one row per order. (On a "Views only" connection, GPTree would read a view of it.) You type into chat:

"How many orders did we take last month?"

GPTree sees that the question asks for a number. A total, a count, an average, "by month", "top 10": questions like these are checked against the connected database. GPTree prepares a read-only query, and the query waits. Nothing has run yet. The answer you get in the meantime is built from documents, and it says that the figure is not available yet and why.

It may ask you which date you mean. If the orders table has more than one date, an order date and a ship date, GPTree asks which one "last month" means. You say the order date.

The query waits where you can read it. Under "Queries waiting" in the Databases section, it shows your question, then the query described in plain words: a count of orders, from the orders table, over the exact dates that "last month" worked out to. Those dates are worked out by code, not by an AI model, in the time zone set on the connection. Any warnings come next, such as a join that could count rows twice. The query itself is behind "Show the query" for anyone who wants to read it.

Someone approves it. On a "Views only" connection that is you. On a "Tables" connection it is an admin of the connection. Either way the check is the same: is that the right table, and are those the right dates? "Run query" runs it. "Cancel" drops it.

You ask again. After the query has run, asking the question again includes the figure. The answer cites the saved result, the way it would cite a document, and states the exact range it measured. Ask the same question again within five minutes and GPTree reuses the result instead of running the query twice.

What this changes, and what it does not

It changes who can check a query. Approving "how many orders did we take last month" takes someone who knows that orders is the right table and that those are the right dates. It does not take someone who can write the query.

It does not take the person out. Nothing runs until it is approved. Approval happens in the Databases section, not inside the chat conversation. A request to approve expires after 24 hours. And the figure appears when you ask again, not by itself.

It does not guess. If a period cannot be turned into exact dates, GPTree says so. If two connected databases both have the table, it asks which database.

It does not widen access. Everyone who can use the connection sees what its database user can see, and GPTree does not add row or column restrictions of its own. If some figures are not for everyone, connect with a database user or views made for the people who will be asking.

It is limited on purpose, to protect the database. Each query has a time limit the database server enforces (30 seconds by default), a cap on the rows returned, a limit on how many rows it may examine, and a limit on how many queries run at once per connection.

Your analyst is still the person to ask what should count as an order in the first place. For the small question before the meeting, you can now ask it yourself and see exactly what was measured.