Skip to content

Today we’re launching Basedash Models — a semantic workspace of reusable, governed SQL for the concepts your company actually runs on.

Definitions grew up. Models now live as a top-level workspace right below Data. A model captures customers, orders, or active accounts once, so everyone works from the same trusted definition instead of re-deriving it.

You reference a model in SQL like a table: select * from models.customers. Legacy definitions. references migrate automatically.

Define it once. Query it like a table.

A workspace, not a SQL snippet

A model is more than a named query. Each one has dedicated editor views for Details, Columns, Measures, and Segments, plus the semantics the rest of Basedash needs to treat it as a real business object:

  • synonyms, so the same concept can be asked for in plain language
  • row grain and key columns, so joins stay honest
  • relationships to other models
  • usage guidance the assistant can actually follow

Models live as a top-level workspace under Data, with Customers, Orders, and Active accounts as shared objects.

This is the evolution of Definitions into a first-class product surface. The SQL is still the source of truth. The workspace is where the team governs it.

Measures and segments live on the model

Core metrics should not live in someone’s private query. On a Customers model, Active customers, MRR, and LTV are measures. Enterprise and Trialing are segments. Relationships, such as Customers to Orders, sit next to them.

Measures, segments, and relationships are first-class parts of the model, not comments in SQL.

When someone on growth, finance, or CS asks for customers, they hit the same object. The calculation does not fork just because the question came from a different Slack thread.

The assistant reads the same semantics

The assistant does not guess which filter you meant. It reads the model: the measures, the segments, the relationships, and the usage guidance. Ask for active enterprise customers and it reaches for the Active customers measure and the Enterprise segment — the ones the team already agreed on.

The assistant reads the Customers model, then answers with the team’s measures and segments.

That is the point of putting semantics on the model instead of hoping the prompt is specific enough. More accurate SQL. The right measures and filters. Consistent with how the team defines things.

Admins can turn Models off per organization in settings if the workspace is not ready for it yet.

Getting started

Basedash Models is available today.

  1. Sign up for Basedash or log in
  2. Open Models in the sidebar, directly under Data
  3. Create or open a model for a core concept (customers, orders, active accounts)
  4. Add measures, segments, and usage guidance
  5. Query it like a table: select * from models.<name> — or ask the assistant and let it read the model

Existing definitions. references keep working and migrate automatically.

Define it once. Query it like a table.

Written by

Max Musing avatar

Max Musing

Founder and CEO of Basedash

Max Musing is the founder and CEO of Basedash, an AI-native business intelligence platform designed to help teams explore analytics and build dashboards without writing SQL. His work focuses on applying large language models to structured data systems, improving query reliability, and building governed analytics workflows for production environments.

View full author profile →

Basedash lets you build charts, dashboards, and reports in seconds using all your data.