> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/references/v1/resources/minerva.md).

# Minerva

Minerva is a dynamic resource in DataOS. It gives you a Trino-based distributed SQL engine that queries depots and lakehouse data through a single endpoint, provisioned on demand.

When you create a Minerva resource, the operator spins up the runtime (coordinator and workers) and the underlying service resources. Once it's ready, the gateway registers Minerva and exposes a Trino-compatible SQL endpoint. From there, any SQL client can query every configured depot as a unified catalog. You don't manage the infrastructure.

Minerva handles:

* A scalable SQL query layer over DataOS depots.
* Catalog configuration from depot references and secrets.
* A query endpoint for BI tools, apps, and notebooks.

## Building blocks

* **Minerva domain definition** - The artifact that bootstraps the Minerva resource type.
* **Minerva resource (dynamic)** - Declarative spec defining compute, depots, and the runtime user (`runAsUser`).
* **Operator** - Poros manages the resource lifecycle and generates the underlying services.
* **Coordinator and workers** - The Trino runtime that executes queries.
* **Depots** - Catalog config and secret projection for accessing data sources.

## Setup and query flow

1. **Verify prerequisites.** Minerva domain exists; required depots are ready.
2. **Write the resource manifest.** Define compute, depots, and `runAsUser`.
3. **Apply it.** Create the dynamic Minerva resource.
4. **Provisioning.** The operator brings up coordinator and worker services.
5. **Gateway registration.** Minerva registers with the gateway over the Trino protocol on port `7432`.
6. **Query.** Users query depots through the Minerva endpoint.

## Create a Minerva resource

Create a Minerva resource after your compute and depots are ready. The manifest defines the runtime, its capacity, and exposed depot catalogs.

Follow [Create a Minerva resource](/references/v1/resources/minerva/create-a-minerva-resource.md) to write, apply, and verify the resource.

## Troubleshoot and monitor Minerva

Use runtime signals to diagnose provisioning, catalog, and query failures. Monitor the coordinator, workers, and catalog initialization after deployment.

See [Troubleshoot and monitor Minerva](/references/v1/resources/minerva/troubleshoot-and-monitor.md) for failure causes, operational guidance, and health signals.

## Query from Workbench

Use Workbench to validate the Minerva connection and explore depot data. Workbench sends SQL through the Minerva endpoint. Each configured Depot appears as a catalog.

Before you begin, verify that the Minerva resource is ready. Your access must also permit querying each target Depot.

### Start a bench

1. Open **Workbench** in DataOS.
2. Select **New bench**.
3. Select your Minerva resource as the query engine.
4. Wait for the catalog browser to load.

### Browse the catalog

Each catalog maps to a Depot declared in the Minerva resource. Expand catalogs to inspect schemas, tables, and columns.

Confirm column names and types before writing a query. A missing catalog can indicate an undeclared or inaccessible Depot.

### Run and refine queries

Start with a narrow query and a limited result set. This confirms the connection and avoids scanning unnecessary data.

Use fully qualified dataset names when the active catalog is unclear: `catalog.schema.table`. Filter, join, or aggregate after validating the expected records.

Save the bench when the query needs reuse or sharing. See [Troubleshoot and monitor Minerva](/references/v1/resources/minerva/troubleshoot-and-monitor.md) for query failures and runtime health checks.

***

## Command reference

A Minerva cluster has no dedicated `dataos-ctl` command group: manage it through the generic `resource` commands, scoped with `-t minerva`.

| Command                                             | Purpose                                            | Reference                                                                                                                   |
| --------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `dataos-ctl resource apply -f <resource-spec.yaml>` | Create or update a Minerva cluster from a manifest | [→ full reference](https://v2.dataos.info/references/interfaces/command-line-interface/resource#dataos-ctl-resource-apply)  |
| `dataos-ctl resource get -t minerva -a`             | List Minerva clusters                              | [→ full reference](https://v2.dataos.info/references/interfaces/command-line-interface/resource#dataos-ctl-resource-get)    |
| `dataos-ctl resource log -t minerva -n <name>`      | Read coordinator/worker logs when troubleshooting  | [→ full reference](https://v2.dataos.info/references/interfaces/command-line-interface/resource#dataos-ctl-resource-log)    |
| `dataos-ctl resource delete -t minerva -n <name>`   | Delete a Minerva cluster                           | [→ full reference](https://v2.dataos.info/references/interfaces/command-line-interface/resource#dataos-ctl-resource-delete) |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/references/v1/resources/minerva.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.