> 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/limitations.md).

# Limitations

## 1. Scalability Considerations

### Fixed Resource Allocation

Minerva clusters are provisioned with predefined compute and memory resources.

#### Considerations

* Resources do not automatically scale based on workload demand.
* Increased workload may require manual cluster resizing.
* Capacity planning is required for growing user bases and workloads.

### Concurrent Query Execution

As the number of users increases, multiple queries compete for the same cluster resources.

#### Potential Impact

* Increased query wait times.
* Resource contention during peak usage.
* Dashboard queries may affect interactive analytics workloads.

### Multi-User Workloads

Shared clusters serving large numbers of users can experience performance degradation when executing complex analytical queries simultaneously.

#### Potential Impact

* Reduced responsiveness.
* Longer dashboard load times.
* Higher infrastructure requirements.

## 2. Query Performance Considerations

### Cross-Source Joins

Minerva supports joins across different data sources and catalogs.

#### Example

* Iceberg ↔ PostgreSQL
* Snowflake ↔ SQL Server
* BigQuery ↔ Iceberg

#### Considerations

* Data movement between systems may be required.
* Network latency can impact performance.
* Large cross-source joins may execute significantly slower than joins within a single platform.

### Memory-Intensive Operations

Certain SQL operations require substantial memory and compute resources.

#### Examples

* Large joins
* Window functions
* Complex aggregations
* DISTINCT operations
* Large ORDER BY operations

#### Potential Impact

* Increased execution time.
* Query failures due to insufficient resources.
* Higher cluster utilization.

### Connector Dependency

Query performance depends heavily on the underlying data source and connector capabilities.

#### Factors Affecting Performance

* Source system performance.
* Connector implementation.
* Predicate pushdown support.
* Aggregation pushdown support.
* Network connectivity.

Different connectors may provide different optimization capabilities.

***

## 3. View Limitations

### Logical Views

Minerva views are logical definitions that store SQL statements rather than physical data.

#### Considerations

* Data is not materialized.
* Underlying queries execute each time the view is accessed.
* Performance depends on the complexity of the view definition.

#### Potential Impact

* Slower dashboard performance.
* Repeated computation of the same logic.
* Increased cluster resource consumption.

### Nested Views

Views built on top of other views increase query complexity.

#### Potential Impact

* More complex execution plans.
* Longer query execution times.
* Increased difficulty in debugging and maintenance.

### Cross-Catalog Views

Views referencing multiple catalogs or data sources may require distributed execution.

#### Potential Impact

* Additional data movement.
* Increased latency.
* Reduced query performance.

***

## 4. Data Product Considerations

### Direct Reporting on Raw Data

Building dashboards directly on raw operational or transactional datasets can lead to inefficient query execution.

#### Challenges

* Large data scans.
* Increased query latency.
* Higher resource consumption.

### Reporting Layer Requirements

For optimal performance, reporting workloads should leverage curated and pre-aggregated datasets rather than raw source tables.

***

## 5. Data Engineering Limitations

### Not a Full ETL Processing Engine

Minerva is designed primarily as a SQL query and analytics engine.

#### Not Recommended For

* Large-scale ETL pipelines.
* Heavy batch processing workloads.
* Complex transformation pipelines.
* Data-intensive processing jobs.

## 6. Operational Considerations

### Monitoring and Troubleshooting

Performance issues may originate from multiple layers of the architecture.

#### Potential Sources

* Source systems.
* Connectors.
* Network infrastructure.
* Cluster resources.
* Query design.

#### Considerations

Root cause analysis often requires investigation across multiple platform components.


---

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