Read-only in layers. Your servers, your sign-on, your model.

Every query Dia's chat writes is checked in code before it runs. The SQL must parse as exactly one statement, that statement must be a read, and nothing inside it may insert, update, delete, merge, create, drop, alter or truncate, including inside a nested sub-query or a common table expression.

The query then runs in a read-only transaction where the database supports one, and the transaction is always rolled back. Connections are read-only unless an administrator marks one writable, and that decision is made per connection, not per user.

A role gets one of four access levels to each connection: unrestricted, metadata-only, granular or blocked. Within granular access, column masks and row filters decide what a role can see, and the answer is built from nothing else. Personal data is classified automatically as a connection is read, so masks can be set before anyone asks a question.

A read-only observer role exists for the auditor and the reviewer. Where you prefer the database to enforce what it already enforces, a user's own credentials can pass through to it.

Dia signs people in through Keycloak, Microsoft Entra ID or any OIDC provider. Roles come from your directory, and a role's access to each connection is set in Dia by an administrator. There are no Dia-only accounts to manage once sign-on is connected.

Dia ships as a Docker Compose stack. It runs on your own servers or in your cloud account, behind your sign-on, and connects to your databases from inside your network. Nothing about your data is sent to Satvi.

Built-in drivers cover PostgreSQL, MySQL, Oracle, SQL Server and Azure SQL, SQLite, DuckDB and BigQuery, and Trino opens the engines it federates.

Underneath, Dia runs the open engines large companies already trust, Kafka, Flink, Trino, Doris, Spark and Iceberg, packaged and operated as one product on your servers. Nothing is hidden behind a proprietary store, and your data stays in open formats.

Dia works with OpenAI, Azure OpenAI and Anthropic, or with Ollama running on your own hardware. The model's only job is to understand the question. It never chooses the joins and it never runs a query, so switching models changes nothing about what Dia is allowed to do.

The audit log records who asked, what Dia understood the question to mean, which approved definitions it used, the SQL that ran and when. An answer can be traced back to its definitions by anyone with access to the log, which is how a reviewer checks an answer after the fact and how IT sees what the business is asking.