How Holistics works

If you want the design argument behind this architecture, read Why Holistics first.

Architecture in one paragraph

Holistics is a thin client on top of your SQL data warehouse. We don't store or process your raw data; your warehouse does. What Holistics adds is an expressive semantic layer where business logic lives as composable code objects, kept durable by an analytics-as-code infrastructure where every definition is version-controlled, reviewable, and promotable. Everything else (dashboards, AI, embedding, self-service) runs on top.

Holistics connects directly to your SQL warehouse

Holistics requires a SQL database. Ideally this is a SQL data warehouse (Snowflake, BigQuery, Redshift, Databricks, Postgres, etc.); in some cases you can connect directly to a production database.

When a user runs an exploration, asks the AI a question, or loads a dashboard, Holistics builds a SQL query and executes it against your warehouse. The result set is then formatted and visualized. Because all heavy lifting happens in the warehouse, you get to use the storage and processing capacity you already pay for, and your raw data never leaves your system. See Data security for details.

Holistics handles the BI tier in your stack: the semantic layer plus everything that runs on top of it (dashboards, AI, embedding, self-service). For transformation, it integrates natively with dbt; for ingestion, use whatever EL/ETL tool you already run.

The semantic layer is where business logic lives

Unlike SQL-to-chart BI tools where users write queries and turn results into charts, Holistics introduces a semantic layer between the warehouse and the people (and AI) that consume data.

The semantic layer itself is written in AML (Analytics Modeling Language): a typed language purpose-built for analytics modeling. Models, dimensions, measures, datasets, and relationships are first-class language constructs (not the YAML key-value structures most BI tools use), and modules, extends, and constants keep code DRY at scale. AML is what makes the semantic layer programmable, the way YAML configs cannot be. See AML vs YAML for the structural contrast.

Layered on top of the AML-defined semantic layer is AQL (Analytics Query Language): a composable query language for metrics. Metrics are first-class objects, not SQL strings, so logic like period comparisons, cohort retention, and ratios across grains stays inside the metric layer instead of leaking into derived tables and spreadsheets. See AQL vs SQL for the structural contrast.

When a user asks a question (through drag-and-drop, through AQL, or through Holistics AI), the request is resolved against the semantic layer, compiled to native SQL, and executed against your warehouse.

This is the foundation that makes AI reliable: AI reasons from the same composable definitions humans use, not from raw schema. See Why Holistics AI is reliable for the full mechanism.

Everything is code, governed by Git

Every definition is stored as code in a Git repository: models, metrics, datasets, dashboards, relationships, permissions. This is what keeps the semantic layer durable.

That means:

• Branches for in-progress work
• Pull requests for review and approval
• Validation at compile time, before code merges
• Environments to promote changes from dev to staging to prod
• History for every change: who, when, and why
• Inspectable compiled SQL so engineers can see exactly what runs

You can edit through the GUI or write code directly in AML Studio: both write to the same code base. See Version Control with Git and the Analytics-as-Code overview for details.

What's next

• Quickstart. The end-to-end builder workflow with videos and screenshots.
• Walkthrough tutorial. Build a dataset and dashboard hands-on, step-by-step.
• Key concepts. Core abstractions and terminology.
• Open semantic layer. Query the semantic layer from notebooks, internal apps, or AI agents.