> 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/concepts/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 and use a Minerva resource

### Prerequisites

* The Minerva domain must exist (usually created at DataOS deployment).
* Compute available for coordinator and worker workloads.
* Depots ready, with valid Secrets.
* To create a Minerva Cluster, you need a tenant-specific role (**Tenant Admin**, **Data Admin**, or **Data Developer**).
* To use a Minerva Cluster, you need resource-specific permission granted by the Minerva Cluster owner.

### Write the manifest

Template (substitute values for your environment):

```yaml
version: v1alpha
type: minerva
name: ${MINERVA_CLUSTER_NAME}

tags:
  - minerva
  - {TAG1}

spec:
  compute: ${MINERVA_COMPUTE_NAME}
  runAsUser: {USERID}
  depots:
    - address: {DEPOT}
```

Example:

```yaml
name: minerva026
version: v1alpha
type: minerva
tags:
  - minerva
  - dataos:type:resource
  - dataos:type:tenant-resource
spec:
  compute: universe-compute
  depots:
    - address: "dataos://mys3lh26depot?purpose=rw"
    - address: "dataos://mygcslh26depot?purpose=rw"
    - address: "dataos://myabfsslh26depot?purpose=rw"
  runAsUser: johndoe
  coordinatorEnvs:
    VERBOSE_CONFIG: "true"
  workerEnvs:
    VERBOSE_CONFIG: "true"
```

### Spec fields

| Field             | What it is                                                 |
| ----------------- | ---------------------------------------------------------- |
| `compute`         | Compute where coordinator and worker services run          |
| `runAsUser`       | Runtime identity used for access control and authorization |
| `depots`          | Depot URIs exposed as catalogs                             |
| `coordinatorEnvs` | Optional environment variables for the coordinator         |
| `workerEnvs`      | Optional environment variables for workers                 |

### Apply

```bash
dataos-ctl resource apply -f resource-spec.yaml
```

### Verify

```bash
dataos-ctl resource get -t minerva -a
```

***

## Troubleshooting

| Failure                      | Cause                                        |
| ---------------------------- | -------------------------------------------- |
| Resource creation fails      | Minerva domain missing                       |
| Catalog initialization fails | Invalid or inaccessible depots or Secrets    |
| Services fail to start       | Compute misconfiguration                     |
| Runtime errors               | Misconfigured coordinator or worker env vars |

***

## Operations

* **Sizing.** Coordinator and worker CPU and memory must match the workload.
* **Depot hygiene.** Invalid Secrets or unreachable depots block catalog setup.
* **Runtime stability.** Make sure the compute pool has capacity.
* **Security.** Keep `runAsUser` and depot Secret scopes least-privilege.

***

## Monitoring

Track both query performance and system health. These are the signals worth watching:

* Query throughput.
* Latency (p50 and p95).
* Error rate.
* CPU and memory on the coordinator and workers.
* Restart frequency.
* Catalog initialization time and failures.

***

## Usage

Once Minerva is registered with the gateway, query it from Workbench over the Trino protocol. The catalogs you see come from the depots configured on the resource.

1. Open Workbench in DataOS.
2. Create a new bench.
3. Select your Minerva resource as the query engine.
4. Browse the depots exposed through Minerva. They appear as catalogs.
5. Pick a depot or catalog.
6. Pick a schema and dataset.
7. Write and run SQL.


---

# 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/concepts/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.