Knowi for
data teams

Join your sources, define your metrics once, and let agents answer on them. No warehouse project first.

Book a demo Explore the platform ↓

Connects natively to SQL, NoSQL and REST APIs. Every dataset has an API, so other systems can read it too.

datasets / customer_360 / query cross-source join
Sources in this dataset
MongoDB · orders aggregation pipeline queried in place
PostgreSQL · customers SQL queried in place
REST · billing API JSON, nested queried in place
customer_360 Cloud9QL join on customer_id saved, certified
moved to a warehouse: nothing | mode: direct or stored, incremental | API endpoint: on

Fewer dashboard requests. One definition for every metric.

A metric that lives in three systems usually needs a pipeline, a staging table and a model before anyone sees a chart. Knowi queries each source where it is, joins them, and saves the result as a governed dataset. Every dashboard, alert and agent reads from that dataset.

The data layer

Three things Knowi does for a data team

Unify your data
Query SQL, NoSQL and REST APIs where they are, and join them. No warehouse first.
Semantic Layer
Define a metric once. Every dashboard, query and agent uses that definition.
AI and Agents
Agents that connect, query, build and deliver, using your definitions.
Unify your data

Each source in its own language

MongoDB is queried with aggregation pipelines, Elasticsearch with its query DSL, each SQL database in its own dialect. Nested JSON stays nested. Any result, including a join across sources, is saved as a reusable dataset with its field mappings and transformations.

  • 70+ native connectors: SQL, NoSQL, REST APIs, SaaS apps, files and documents
  • Joins across sources in Cloud9QL, no staging tables
  • Direct mode queries the source live. Stored mode keeps a copy with incremental updates, in Knowi or in your warehouse
  • Role-based and row-level security set on the dataset, applied to everything built on it
How unified data works
Query languages, per source
mongodbAggregation pipelinenative
elasticQuery DSLnative
postgresSQLnative
rest apiJSON, nested arrays intactnative
joinCloud9QL across all of the abovequery time
Semantic Layer

Define each metric once

A glossary term holds the definition and the exact dataset and field it points to. The definition runs, rather than sitting in a document someone has to remember. Agents read it before they write a query.

  • Terms, aliases and field mappings, scoped account-wide or to one dataset
  • A person certifies each term. Certified terms rank first in answers
  • AI can draft descriptions. A person reviews and publishes them
  • Lineage per field, account-wide rules for fiscal calendar and currency, all available over MCP
How the semantic layer works
glossary / revenue
termRevenue → sales_facts.net_bookedcertified
aliasesbookings, net revenue, rev3 mapped
ruleFiscal year starts Feb 1account-wide
lineageorders × customers × billingtraceable
editSemantic edit + asset accessrole-scoped
AI and Agents

Agents that use your definitions

Someone asks a question in plain English. An orchestrator sends it to the right agent: connect a source, run the query, build the dashboard, send the report, set the alert. Every step reads the semantic layer first, and you can trace each answer back to the term and field it used.

  • More than 20 specialized agents inside the data layer, with access to your schema and field types
  • Knowi AI by default. OpenAI or Claude optional per feature. Your own model when self-hosted
  • The same agents work inside Claude or any MCP client, through the Knowi MCP server
  • Every answer respects the user's permissions and row-level filters
How Knowi agents work
ask / "net revenue by region, last quarter"
resolvenet revenue → Revenue (certified)glossary
resolvelast quarter → fiscal Q2, Feb 1 startrule
querycustomer_360, filtered to the asker's rowsrls
buildBar chart, region × net_bookedwidget
deliverSlack, #finance, as a chartsent
Where it sits

Works with any source

Most semantic layers need everything loaded and modeled into a warehouse first. In Knowi, the warehouse is one source among the rest.

Warehouse-first stack
Knowi
Prerequisite
Data has to be loaded into the warehouse first
Live sources as they are. Your warehouse is one of them
Modeling work
LookML, YAML or cube definitions written by hand
The saved dataset is the model
Sources covered
SQL warehouses
SQL, NoSQL, REST APIs and documents, 70+ connectors
Cross-source metric
Join in ETL first, then model the result
One Cloud9QL join across sources, saved as a dataset

Stored datasets can be sent to your warehouse if you want them there.

Governance & deployment

Governance you can show an auditor

Access is set on the dataset and applies to everything built on it. Deploy wherever your data is allowed to be.

Security
Access control, SSO and audit trail
Role-based access, row-level security, SSO via SAML and OpenID Connect, and a full audit trail of data access and queries. SOC 2 Type II.
Explore security →
Deployment
Cloud, VPC or your own infrastructure
Managed Knowi Cloud, your VPC, or on-premises with Docker or Kubernetes. The AI engine runs inside your deployment.
Explore deployment options →
Customer results

Data teams running on Knowi

Electronics manufacturing · MacroFab
"While we selected Knowi as a viz tool, I'm also happy we did so from a data engineering perspective. Knowi's architecture models data thoughtfully, which I'd credit for enabling a collection of elegant features."
Phil BryantVP Business Intelligence, MacroFab
Read the MacroFab story →
Marketing & AdTech · Ampush
Migrated from Tableau. Consolidated analytics across channels and clients into unified dashboards with a single source of truth, and cut total cost of ownership by half.
AmpushCustomer story
Read the Ampush story →
FAQ

What data teams ask on the first call

We already run Snowflake and dbt. Does Knowi replace them or sit alongside?

Alongside. Snowflake is one of the 70+ sources, and Knowi queries it with SQL like any other. The difference shows when a metric needs Snowflake plus MongoDB plus a REST API. In Knowi that is one Cloud9QL join saved as a dataset. Without Knowi it is a pipeline to load the other two sources into the warehouse first.

How does Knowi handle deeply nested JSON from MongoDB or an API?

Natively. The MongoDB connector runs aggregation pipelines and the REST connector reads nested JSON as it arrives. Arrays and sub-documents are queried as they are, not flattened on the way in. If you want to unnest, you do it in Cloud9QL at the step you choose.

What is Cloud9QL and do we have to learn it?

Cloud9QL is Knowi's SQL-like language for joining, transforming and aggregating results from different sources. Each source is still queried in its own language. Cloud9QL works on the results. If you write SQL, you can read it on day one.

How do stored datasets stay fresh?

Each dataset is either Direct, which queries the sources live, or Stored, which keeps a copy with incremental updates. Stored results live in Knowi or in your warehouse. You choose per dataset: a heavy join can be stored while a fast query stays live.

How do we stop the AI from inventing a definition of revenue?

Define it before the AI runs. A glossary term points to a specific dataset and field, aliases map synonyms to it, and the primary date field settles what "last quarter" means. The agent uses that definition instead of guessing at column names, and you can trace how each question was resolved. Certified terms rank first.

Can other systems read a Knowi dataset without going through a dashboard?

Yes. Every dataset has an API, so other systems can read it directly. The semantic layer is also available through the Knowi MCP server: list glossary terms, map them, set dataset semantics and see how a question was resolved, from Claude or any MCP client.

Bring the join you have been putting off

Name the two or three sources. A solutions engineer builds the dataset live on the call, on your data or a sample of it.

Book a demo Read the docs

30 minutes · Deployment and pricing covered on the call.