From 2e10baf8b4dc8d002de9b2f821bcc2b6633189fe Mon Sep 17 00:00:00 2001
From: Artyom Keydunov <artyom@cube.dev>
Date: Wed, 20 May 2026 12:43:30 -0700
Subject: [PATCH 1/4] docs: clean up Monitoring Integrations section (#10922)

- Reposition Monitoring Integrations as an Enterprise add-on (no tiers)
  on the index page, limits page, and pricing page.
- Replace large vendor-logo cards with title + description cards in a
  3-column grid.
- Rename the index page title from "Strategy, credentials, etc." to
  "Overview" and drop the orphan migration-leftover heading.
- Make the Query History export callout state explicitly that it is
  part of the Monitoring Integrations add-on.
- Use a shorter sidebar label for the Query History export recipe.

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../admin/account-billing/pricing.mdx         | 18 +++-------
 docs-mintlify/admin/deployment/limits.mdx     |  9 +++--
 .../monitoring-integrations/index.mdx         | 35 ++++++++++---------
 .../admin/monitoring/query-history-export.mdx |  1 +
 4 files changed, 28 insertions(+), 35 deletions(-)

diff --git a/docs-mintlify/admin/account-billing/pricing.mdx b/docs-mintlify/admin/account-billing/pricing.mdx
index a199e1d34f15d..6bb6262938ebf 100644
--- a/docs-mintlify/admin/account-billing/pricing.mdx
+++ b/docs-mintlify/admin/account-billing/pricing.mdx
@@ -96,7 +96,7 @@ of deployments within a Cube Cloud account. The consumption is measured in 5-min
 | Cube Store Worker | <nobr>1..2</nobr> | Depends on a [chosen tier](#cube-store-worker-tiers) |
 | [Semantic Catalog][ref-semantic-catalog] | <nobr>2..4</nobr> | Depends on a [chosen tier](#semantic-catalog-tiers) |
 | [Query History][ref-query-history] | <nobr>0..20</nobr> | Depends on a [chosen tier](#query-history-tiers) |
-| [Monitoring Integrations][ref-monitoring-integrations] | <nobr>1..4</nobr> | Depends on a [chosen tier](#monitoring-integrations-tiers) |
+| [Monitoring Integrations][ref-monitoring-integrations] | — | Available as an [add-on](#monitoring-integrations) on the Enterprise plan |
 
 The following resource types incur CCU consumption and apply to the _whole Cube Cloud
 account_:
@@ -169,18 +169,11 @@ features analyze and visualize the data available under the following tiers:
 You can upgrade to a chosen tier in the
 **Settings** of your deployment.
 
-### Monitoring Integrations tiers
+### Monitoring Integrations
 
-[Monitoring Integrations][ref-monitoring-integrations] feature has the following tiers:
-
-| Tier | CCUs per hour | Exported data  | Dependent features |
-| ---- | :-----------: | -------------- | --- |
-| XS   | 1             | Up to 10 GB/mo | — |
-| S    | 2             | Up to 25 GB/mo | — |
-| M    | 4             | Up to 50 GB/mo | [Query History export][ref-query-history-export] |
-
-You can [upgrade][ref-monitoring-integrations-config] to a chosen tier in the
-**Settings** of your deployment.
+[Monitoring Integrations][ref-monitoring-integrations], including [Query History
+export][ref-query-history-export], are available as an add-on on the Enterprise
+plan. [Contact us][cube-contact-us] for pricing.
 
 ### Audit Log tiers
 
@@ -330,7 +323,6 @@ for the AI token consumption at the **Billing** page of their Cube Cloud account
 [ref-cloud-deployment-prod-cluster]: /docs/deployment/cloud/deployment-types#dedicated
 [ref-cloud-limits]: /docs/deployment/cloud/limits
 [ref-monitoring-integrations]: /docs/monitoring/integrations
-[ref-monitoring-integrations-config]: /admin/deployment/monitoring-integrations#configuration
 [ref-cloud-acl]: /admin/users-and-permissions/custom-roles
 [ref-cloud-deployment-prod-multicluster]: /docs/deployment/cloud/deployment-types#multi-cluster
 [ref-cloud-custom-domains]: /docs/deployment/cloud/custom-domains
diff --git a/docs-mintlify/admin/deployment/limits.mdx b/docs-mintlify/admin/deployment/limits.mdx
index 69c2729b4af04..601e6fceca401 100644
--- a/docs-mintlify/admin/deployment/limits.mdx
+++ b/docs-mintlify/admin/deployment/limits.mdx
@@ -35,7 +35,7 @@ types][ref-deployment-types] and [product tiers][ref-pricing]:
 | [Query History][ref-query-history] — queries processed per day for each deployment  |   1,000   | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] |
 | [Audit Log][ref-audit-log] — retention period                                       |     —     |     —     |     —     | 30 days    |
 | [Audit Log][ref-audit-log] — events collected                                       |     —     |     —     |     —     | 10,000     |
-| [Monitoring Integrations][ref-monitoring-integrations] — exported data              |     —     | Depends on the [tier][ref-monitoring-integrations-tiers] | Depends on the [tier][ref-monitoring-integrations-tiers] | Depends on the [tier][ref-monitoring-integrations-tiers] |
+| [Monitoring Integrations][ref-monitoring-integrations] — exported data              |     —     |     —     |     —     | Available as an [add-on][ref-monitoring-integrations] |
 
 ### Number of deployments
 
@@ -82,8 +82,8 @@ support][cube-contact-us] for further assistance.
 
 ### Data exported via Monitoring Integrations
 
-This is a hard limit. Consider upgrading to the next [Monitoring Integrations tier][ref-monitoring-integrations-tiers].
-Usage is calculated per Cube Cloud deployment.
+This is a hard limit. Usage is calculated per Cube Cloud deployment. [Contact
+support][cube-contact-us] for higher quotas.
 
 ## Quotas
 
@@ -105,5 +105,4 @@ response.
 [ref-prod-cluster]: /docs/deployment/cloud/deployment-types#dedicated
 [cube-contact-us]: https://cube.dev/contact
 [ref-query-history-tiers]: /admin/account-billing/pricing#query-history-tiers
-[ref-audit-log]: /admin/monitoring/audit-log
-[ref-monitoring-integrations-tiers]: /admin/account-billing/pricing#monitoring-integrations-tiers
\ No newline at end of file
+[ref-audit-log]: /admin/monitoring/audit-log
\ No newline at end of file
diff --git a/docs-mintlify/admin/monitoring/monitoring-integrations/index.mdx b/docs-mintlify/admin/monitoring/monitoring-integrations/index.mdx
index ad857b0bc5cc5..8a4c5771eb43e 100644
--- a/docs-mintlify/admin/monitoring/monitoring-integrations/index.mdx
+++ b/docs-mintlify/admin/monitoring/monitoring-integrations/index.mdx
@@ -1,18 +1,15 @@
 ---
-title: Strategy, credentials, etc.
+title: Overview
 description: Export Cube Cloud logs and metrics to external monitoring tools like Datadog, Grafana Cloud, and New Relic.
 ---
 
- Monitoring Integrations
-
 Cube Cloud allows exporting logs and metrics to external monitoring tools so you
 can leverage your existing monitoring stack and retain logs and metrics for the
 long term.
 
 <Note>
 
-Available on [Enterprise plan](https://cube.dev/pricing).
-You can also choose a [Monitoring Integrations tier](/admin/account-billing/pricing#monitoring-integrations-tiers).
+Available as an add-on on the [Enterprise plan](https://cube.dev/pricing).
 
 </Note>
 
@@ -47,16 +44,21 @@ destinations][vector-docs-sinks], also known as _sinks_.
 Monitoring integrations work with various popular monitoring tools. Check the
 following guides and configuration examples to get tool-specific instructions:
 
-<CardGroup cols={2}>
-  <Card title="Amazon CloudWatch" img="https://static.cube.dev/icons/aws.svg" href="/admin/monitoring/monitoring-integrations/cloudwatch">
+<CardGroup cols={3}>
+  <Card title="Amazon CloudWatch" href="/admin/monitoring/monitoring-integrations/cloudwatch">
+    Export logs and metrics to Amazon CloudWatch.
   </Card>
-  <Card title="Amazon S3" img="https://static.cube.dev/icons/aws.svg" href="/admin/monitoring/monitoring-integrations/s3">
+  <Card title="Amazon S3" href="/admin/monitoring/monitoring-integrations/s3">
+    Archive logs to an Amazon S3 bucket.
   </Card>
-  <Card title="Datadog" img="https://static.cube.dev/icons/datadog.svg" href="/admin/monitoring/monitoring-integrations/datadog">
+  <Card title="Datadog" href="/admin/monitoring/monitoring-integrations/datadog">
+    Export logs and metrics to Datadog.
   </Card>
-  <Card title="Grafana Cloud" img="https://static.cube.dev/icons/grafana.svg" href="/admin/monitoring/monitoring-integrations/grafana-cloud">
+  <Card title="Grafana Cloud" href="/admin/monitoring/monitoring-integrations/grafana-cloud">
+    Export logs and metrics to Grafana Cloud.
   </Card>
-  <Card title="New Relic" img="https://static.cube.dev/icons/new-relic.svg" href="/admin/monitoring/monitoring-integrations/new-relic">
+  <Card title="New Relic" href="/admin/monitoring/monitoring-integrations/new-relic">
+    Export logs and metrics to New Relic.
   </Card>
 </CardGroup>
 
@@ -64,8 +66,7 @@ following guides and configuration examples to get tool-specific instructions:
 
 To enable monitoring integrations, navigate to **Settings → Monitoring
 Integrations** and click **Enable Vector** to add a Vector agent to
-your deployment. You can use the dropdown to select a [Monitoring Integrations
-tier](/admin/account-billing/pricing#monitoring-integrations-tiers).
+your deployment.
 
 <Frame>
   <img src="https://ucarecdn.com/bf05182f-bbb0-4c20-a95e-ca7aeb03829e/" />
@@ -283,12 +284,12 @@ external monitoring solution for further analysis, for example:
 * Set up alerts for queries that exceed a certain duration.
 * Attribute usage to specific users and implement chargebacks.
 
-<Info>
+<Note>
 
-Requires the [M tier](/admin/account-billing/pricing#monitoring-integrations-tiers)
-of Monitoring Integrations.
+Query History export is part of the Monitoring Integrations add-on,
+available on the [Enterprise plan](https://cube.dev/pricing).
 
-</Info>
+</Note>
 
 <iframe
   width="100%"
diff --git a/docs-mintlify/admin/monitoring/query-history-export.mdx b/docs-mintlify/admin/monitoring/query-history-export.mdx
index b45429d93f284..6b178a6c9c217 100644
--- a/docs-mintlify/admin/monitoring/query-history-export.mdx
+++ b/docs-mintlify/admin/monitoring/query-history-export.mdx
@@ -1,5 +1,6 @@
 ---
 title: Analyzing data from Query History export
+sidebarTitle: Query History export
 description: Walk through exporting Query History to Amazon S3 with Vector and analyzing the files with DuckDB inside Cube.
 ---
 

From 9a60ab55571cf0d42668bc47b808090f6c081256 Mon Sep 17 00:00:00 2001
From: Artyom Keydunov <artyom@cube.dev>
Date: Wed, 20 May 2026 13:18:44 -0700
Subject: [PATCH 2/4] docs: add multi-agent orchestration section to
 agent-to-agent recipe (#10924)

Explain how an orchestrating agent routes questions across multiple Cube
agents by POSTing to each agent's Chat API URL. Cover system-prompt
listing vs. a discovery tool, with a worked LangChain example.

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 docs-mintlify/recipes/ai/agent-to-agent.mdx | 105 ++++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/docs-mintlify/recipes/ai/agent-to-agent.mdx b/docs-mintlify/recipes/ai/agent-to-agent.mdx
index c521c57ac09cc..6e79763036629 100644
--- a/docs-mintlify/recipes/ai/agent-to-agent.mdx
+++ b/docs-mintlify/recipes/ai/agent-to-agent.mdx
@@ -364,6 +364,111 @@ With this approach, the second question — *"Now break that down by
 product line"* — is understood in the context of the first, just like a
 human conversation.
 
+### Orchestrating multiple Cube agents
+
+If your deployment uses [multi-agent][ref-multi-agent] — with specialized
+Cube agents like a Sales Assistant and a Marketing Analyst living in the
+same deployment — your orchestrating agent can choose the right Cube
+agent for each question and route to it.
+
+The [Chat API URL](#endpoint) embeds an `agentId`, so every agent in
+your deployment has its own Chat API URL. Copy each one from **Admin →
+Agents** for the corresponding agent. Switching between Cube agents
+from your code is then just a matter of POSTing to a different URL —
+the request shape is identical.
+
+How your orchestrating agent learns which Cube agents exist is up to
+you. Two common patterns:
+
+- **List them in the system prompt.** Hardcode the agents (name,
+  description, the domain each one covers) in your orchestrator's
+  system prompt. Simple, and works well when the set of agents rarely
+  changes.
+- **Expose a discovery tool.** Add a `list_cube_agents` tool that
+  returns the available agents at runtime. Useful when agents come and
+  go, or when you want the orchestrator to pick them up without a code
+  change.
+
+The example below combines both: a `list_cube_agents` tool for
+discovery and a single `ask_cube_agent` tool that takes an agent name
+plus the question and routes the request to the matching Chat API URL.
+It builds on the `query_cube_agent` helper from above, extended to
+accept a `chat_api_url` argument instead of using a single hardcoded
+URL.
+
+```python
+import json
+import os
+from langchain_core.tools import tool
+
+
+CUBE_AGENTS = {
+    "sales-assistant": {
+        "url": os.environ["CUBE_SALES_AGENT_URL"],
+        "description": (
+            "Sales pipeline, deals, reps, quotas, and revenue by territory."
+        ),
+    },
+    "marketing-analyst": {
+        "url": os.environ["CUBE_MARKETING_AGENT_URL"],
+        "description": (
+            "Campaigns, channel attribution, traffic sources, and funnel "
+            "conversion."
+        ),
+    },
+}
+
+
+@tool
+def list_cube_agents() -> str:
+    """List the available Cube agents and the domain each one covers.
+    Call this first when you need data, then pick the most relevant
+    agent for the user's question."""
+
+    return json.dumps(
+        {name: agent["description"] for name, agent in CUBE_AGENTS.items()}
+    )
+
+
+@tool
+def ask_cube_agent(agent_name: str, question: str) -> str:
+    """Ask a data analytics question to a specific Cube agent.
+
+    Call `list_cube_agents` first to see which agents are available and
+    which domain each one covers, then pass the chosen `agent_name`
+    along with a focused, self-contained question."""
+
+    agent = CUBE_AGENTS.get(agent_name)
+    if agent is None:
+        available = ", ".join(CUBE_AGENTS.keys())
+        return (
+            f"Unknown Cube agent '{agent_name}'. "
+            f"Available agents: {available}."
+        )
+
+    return query_cube_agent(question, chat_api_url=agent["url"])
+```
+
+<Info>
+
+Alternatively, skip the discovery tool entirely and inline the list of
+agents and their domains in your orchestrator's system prompt. The
+orchestrator will then pass an `agent_name` directly to `ask_cube_agent`
+without an extra round trip.
+
+</Info>
+
+This pattern gives your orchestrating agent a clean routing layer: it
+picks the right Cube agent for each question, and each Cube agent
+answers using the rules, certified queries, and accessible views
+configured for its [space][ref-spaces]. A sales question is routed to
+the Sales Assistant and answered against the sales views; a marketing
+question is routed to the Marketing Analyst and answered against the
+marketing views — without your orchestrator needing to know any of
+those details.
+
 
 [ref-chat-api]: /reference/embed-apis/chat-api
 [ref-api-keys]: /admin/account-billing/api-keys
+[ref-multi-agent]: /admin/ai/multi-agent
+[ref-spaces]: /admin/ai/multi-agent#spaces

From 858c1e450f0279d1139088122746ea8253edbf6b Mon Sep 17 00:00:00 2001
From: waralexrom <108349432+waralexrom@users.noreply.github.com>
Date: Wed, 20 May 2026 23:12:52 +0200
Subject: [PATCH 3/4] feat(cubestore): Fold IS NOT DISTINCT FROM join
 predicates into HashJoin keys (#10923)

---
 .../is_not_distinct_from_join_test.rs         | 371 ++++++++++++++++++
 .../cubestore/src/queryplanner/mod.rs         |   4 +
 .../is_not_distinct_from_join_keys.rs         |  91 +++++
 .../src/queryplanner/optimizations/mod.rs     |   1 +
 4 files changed, 467 insertions(+)
 create mode 100644 rust/cubestore/cubestore/src/queryplanner/is_not_distinct_from_join_test.rs
 create mode 100644 rust/cubestore/cubestore/src/queryplanner/optimizations/is_not_distinct_from_join_keys.rs

diff --git a/rust/cubestore/cubestore/src/queryplanner/is_not_distinct_from_join_test.rs b/rust/cubestore/cubestore/src/queryplanner/is_not_distinct_from_join_test.rs
new file mode 100644
index 0000000000000..4e58b3c84c289
--- /dev/null
+++ b/rust/cubestore/cubestore/src/queryplanner/is_not_distinct_from_join_test.rs
@@ -0,0 +1,371 @@
+//! Verifies `IsNotDistinctFromJoinKeysRule`: `IS NOT DISTINCT FROM` predicates
+//! in a JOIN's ON clause are lifted into equi-keys with `null_equals_null = true`,
+//! so DF's physical planner picks `HashJoinExec` instead of `NestedLoopJoinExec`
+//! and NULL keys still match.
+
+use std::sync::Arc;
+
+use datafusion::arrow::array::{Int32Array, RecordBatch};
+use datafusion::arrow::datatypes::{DataType, Field, Schema};
+use datafusion::arrow::util::pretty::pretty_format_batches;
+use datafusion::datasource::MemTable;
+use datafusion::logical_expr::LogicalPlan;
+use datafusion::physical_plan::{displayable, ExecutionPlan};
+use datafusion::prelude::{SessionConfig, SessionContext};
+
+use crate::queryplanner::QueryPlannerImpl;
+
+fn make_table(rows: &[(Option<i32>, Option<i32>)]) -> Arc<MemTable> {
+    let schema = Arc::new(Schema::new(vec![
+        Field::new("a", DataType::Int32, true),
+        Field::new("b", DataType::Int32, true),
+    ]));
+    let col_a = Int32Array::from(rows.iter().map(|(a, _)| *a).collect::<Vec<_>>());
+    let col_b = Int32Array::from(rows.iter().map(|(_, b)| *b).collect::<Vec<_>>());
+    let batch =
+        RecordBatch::try_new(schema.clone(), vec![Arc::new(col_a), Arc::new(col_b)]).unwrap();
+    Arc::new(MemTable::try_new(schema, vec![vec![batch]]).unwrap())
+}
+
+/// Table with a non-null `tag` column. A successful LEFT JOIN match against
+/// a NULL-bearing row in this table is visible in the result because `tag`
+/// remains non-null, distinguishing it from LEFT-padding.
+fn make_tagged_table(tag: i32, rows: &[(Option<i32>, Option<i32>)]) -> Arc<MemTable> {
+    let schema = Arc::new(Schema::new(vec![
+        Field::new("a", DataType::Int32, true),
+        Field::new("b", DataType::Int32, true),
+        Field::new("tag", DataType::Int32, false),
+    ]));
+    let col_a = Int32Array::from(rows.iter().map(|(a, _)| *a).collect::<Vec<_>>());
+    let col_b = Int32Array::from(rows.iter().map(|(_, b)| *b).collect::<Vec<_>>());
+    let col_tag = Int32Array::from(vec![tag; rows.len()]);
+    let batch = RecordBatch::try_new(
+        schema.clone(),
+        vec![Arc::new(col_a), Arc::new(col_b), Arc::new(col_tag)],
+    )
+    .unwrap();
+    Arc::new(MemTable::try_new(schema, vec![vec![batch]]).unwrap())
+}
+
+async fn optimized_logical(ctx: &SessionContext, sql: &str) -> LogicalPlan {
+    let plan = ctx.sql(sql).await.unwrap().logical_plan().clone();
+    ctx.state().optimize(&plan).unwrap()
+}
+
+async fn physical(ctx: &SessionContext, sql: &str) -> Arc<dyn ExecutionPlan> {
+    let opt = optimized_logical(ctx, sql).await;
+    ctx.state().create_physical_plan(&opt).await.unwrap()
+}
+
+async fn run(ctx: &SessionContext, sql: &str) -> String {
+    let batches = ctx.sql(sql).await.unwrap().collect().await.unwrap();
+    pretty_format_batches(&batches).unwrap().to_string()
+}
+
+fn count_exec(plan: &dyn ExecutionPlan, needle: &str) -> usize {
+    displayable(plan)
+        .indent(true)
+        .to_string()
+        .matches(needle)
+        .count()
+}
+
+fn assert_plan_str(actual: String, expected: &str) {
+    let actual = actual.trim();
+    let expected = expected.trim();
+    assert_eq!(
+        actual, expected,
+        "\nexpected:\n{expected}\n\nactual:\n{actual}"
+    );
+}
+
+fn ab_context() -> SessionContext {
+    let ctx = QueryPlannerImpl::make_execution_context(SessionConfig::new());
+    let rows = &[
+        (Some(1), Some(10)),
+        (None, Some(20)),
+        (Some(3), None),
+        (None, None),
+        (Some(4), Some(40)),
+    ];
+    let b_rows = &[
+        (Some(1), Some(10)),
+        (None, Some(20)),
+        (Some(3), None),
+        (None, None),
+        (Some(5), Some(50)),
+    ];
+    ctx.register_table("a", make_table(rows)).unwrap();
+    ctx.register_table("b", make_table(b_rows)).unwrap();
+    ctx
+}
+
+const ORDER: &str = "ORDER BY a_a NULLS LAST, a_b NULLS LAST";
+
+#[tokio::test]
+async fn equality_join_uses_hash_join_and_excludes_null_keys() {
+    let ctx = ab_context();
+    let sql = &format!(
+        "SELECT a.a AS a_a, a.b AS a_b, b.a AS b_a, b.b AS b_b \
+         FROM a LEFT JOIN b ON a.a = b.a AND a.b = b.b {ORDER}"
+    );
+
+    let logical = optimized_logical(&ctx, sql).await;
+    assert!(
+        logical
+            .display_indent()
+            .to_string()
+            .contains("Left Join: a.a = b.a, a.b = b.b"),
+        "expected equi-keys lifted into ON, got:\n{}",
+        logical.display_indent()
+    );
+
+    let physical = physical(&ctx, sql).await;
+    assert_eq!(count_exec(physical.as_ref(), "HashJoinExec"), 1);
+    assert_eq!(count_exec(physical.as_ref(), "NestedLoopJoinExec"), 0);
+
+    assert_plan_str(
+        run(&ctx, sql).await,
+        "\
++-----+-----+-----+-----+
+| a_a | a_b | b_a | b_b |
++-----+-----+-----+-----+
+| 1   | 10  | 1   | 10  |
+| 3   |     |     |     |
+| 4   | 40  |     |     |
+|     | 20  |     |     |
+|     |     |     |     |
++-----+-----+-----+-----+",
+    );
+}
+
+#[tokio::test]
+async fn is_not_distinct_from_folds_into_hash_join_keys() {
+    let ctx = ab_context();
+    let sql = &format!(
+        "SELECT a.a AS a_a, a.b AS a_b, b.a AS b_a, b.b AS b_b \
+         FROM a LEFT JOIN b \
+         ON (a.a IS NOT DISTINCT FROM b.a) AND (a.b IS NOT DISTINCT FROM b.b) \
+         {ORDER}"
+    );
+
+    let logical = optimized_logical(&ctx, sql).await;
+    assert!(
+        logical
+            .display_indent()
+            .to_string()
+            .contains("Left Join: a.a = b.a, a.b = b.b"),
+        "expected IS NOT DISTINCT FROM predicates lifted into ON, got:\n{}",
+        logical.display_indent()
+    );
+
+    let physical = physical(&ctx, sql).await;
+    assert_eq!(
+        count_exec(physical.as_ref(), "HashJoinExec"),
+        1,
+        "expected one HashJoinExec, got plan:\n{}",
+        displayable(physical.as_ref()).indent(true)
+    );
+    assert_eq!(
+        count_exec(physical.as_ref(), "NestedLoopJoinExec"),
+        0,
+        "rule failed to lift IS NOT DISTINCT FROM, plan:\n{}",
+        displayable(physical.as_ref()).indent(true)
+    );
+
+    assert_plan_str(
+        run(&ctx, sql).await,
+        "\
++-----+-----+-----+-----+
+| a_a | a_b | b_a | b_b |
++-----+-----+-----+-----+
+| 1   | 10  | 1   | 10  |
+| 3   |     | 3   |     |
+| 4   | 40  |     |     |
+|     | 20  |     | 20  |
+|     |     |     |     |
++-----+-----+-----+-----+",
+    );
+}
+
+#[tokio::test]
+async fn is_not_distinct_from_lifts_many_predicates() {
+    let ctx = QueryPlannerImpl::make_execution_context(SessionConfig::new());
+
+    let schema = Arc::new(Schema::new(vec![
+        Field::new("k1", DataType::Int32, true),
+        Field::new("k2", DataType::Int32, true),
+        Field::new("k3", DataType::Int32, true),
+        Field::new("k4", DataType::Int32, true),
+        Field::new("k5", DataType::Int32, true),
+    ]));
+    let rows: Vec<(
+        Option<i32>,
+        Option<i32>,
+        Option<i32>,
+        Option<i32>,
+        Option<i32>,
+    )> = vec![
+        (Some(1), None, Some(3), None, Some(5)),
+        (None, None, None, None, None),
+        (Some(1), Some(2), Some(3), Some(4), Some(5)),
+        (None, Some(2), Some(3), Some(4), Some(5)),
+    ];
+    let int_col = |idx: fn(
+        &(
+            Option<i32>,
+            Option<i32>,
+            Option<i32>,
+            Option<i32>,
+            Option<i32>,
+        ),
+    ) -> Option<i32>|
+     -> Int32Array { Int32Array::from(rows.iter().map(idx).collect::<Vec<_>>()) };
+    let batch = RecordBatch::try_new(
+        schema.clone(),
+        vec![
+            Arc::new(int_col(|r| r.0)),
+            Arc::new(int_col(|r| r.1)),
+            Arc::new(int_col(|r| r.2)),
+            Arc::new(int_col(|r| r.3)),
+            Arc::new(int_col(|r| r.4)),
+        ],
+    )
+    .unwrap();
+    let make = || Arc::new(MemTable::try_new(schema.clone(), vec![vec![batch.clone()]]).unwrap());
+    ctx.register_table("a", make()).unwrap();
+    ctx.register_table("b", make()).unwrap();
+
+    let sql = "SELECT a.k1, a.k2, a.k3, a.k4, a.k5, \
+                      b.k1 AS b1, b.k2 AS b2, b.k3 AS b3, b.k4 AS b4, b.k5 AS b5 \
+               FROM a LEFT JOIN b \
+               ON (a.k1 IS NOT DISTINCT FROM b.k1) \
+              AND (a.k2 IS NOT DISTINCT FROM b.k2) \
+              AND (a.k3 IS NOT DISTINCT FROM b.k3) \
+              AND (a.k4 IS NOT DISTINCT FROM b.k4) \
+              AND (a.k5 IS NOT DISTINCT FROM b.k5) \
+               ORDER BY a.k1 NULLS LAST, a.k2 NULLS LAST";
+
+    let logical = optimized_logical(&ctx, sql).await;
+    let logical_str = logical.display_indent().to_string();
+    assert!(
+        logical_str
+            .contains("Left Join: a.k1 = b.k1, a.k2 = b.k2, a.k3 = b.k3, a.k4 = b.k4, a.k5 = b.k5"),
+        "expected all 5 IS NOT DISTINCT FROM predicates lifted, got:\n{logical_str}"
+    );
+
+    let physical = physical(&ctx, sql).await;
+    assert_eq!(count_exec(physical.as_ref(), "HashJoinExec"), 1);
+    assert_eq!(count_exec(physical.as_ref(), "NestedLoopJoinExec"), 0);
+
+    assert_plan_str(
+        run(&ctx, sql).await,
+        "\
++----+----+----+----+----+----+----+----+----+----+
+| k1 | k2 | k3 | k4 | k5 | b1 | b2 | b3 | b4 | b5 |
++----+----+----+----+----+----+----+----+----+----+
+| 1  | 2  | 3  | 4  | 5  | 1  | 2  | 3  | 4  | 5  |
+| 1  |    | 3  |    | 5  | 1  |    | 3  |    | 5  |
+|    | 2  | 3  | 4  | 5  |    | 2  | 3  | 4  | 5  |
+|    |    |    |    |    |    |    |    |    |    |
++----+----+----+----+----+----+----+----+----+----+",
+    );
+}
+
+#[tokio::test]
+async fn full_outer_via_driver_chain_uses_hash_joins() {
+    // FULL OUTER emulation:
+    //   keys = SELECT DISTINCT (a, b) FROM (A UNION ALL B UNION ALL C)
+    //   keys LEFT JOIN A LEFT JOIN B LEFT JOIN C, all on keys.k IS NOT DISTINCT FROM X.k
+    // Every ON references the driver, so LEFT-padded NULLs never feed into a
+    // downstream ON.
+    let ctx = QueryPlannerImpl::make_execution_context(SessionConfig::new());
+
+    let a = make_tagged_table(1, &[(Some(1), Some(10)), (None, None)]);
+    let b = make_tagged_table(2, &[(None, Some(20)), (None, None)]);
+    let c = make_tagged_table(3, &[(Some(3), None), (None, None)]);
+    ctx.register_table("a", a).unwrap();
+    ctx.register_table("b", b).unwrap();
+    ctx.register_table("c", c).unwrap();
+
+    let sql = "WITH keys AS ( \
+                  SELECT DISTINCT a, b FROM ( \
+                      SELECT a, b FROM a \
+                      UNION ALL SELECT a, b FROM b \
+                      UNION ALL SELECT a, b FROM c \
+                  ) \
+               ) \
+               SELECT keys.a AS k_a, keys.b AS k_b, \
+                      a.tag AS in_a, b.tag AS in_b, c.tag AS in_c \
+               FROM keys \
+               LEFT JOIN a \
+                 ON (keys.a IS NOT DISTINCT FROM a.a) AND (keys.b IS NOT DISTINCT FROM a.b) \
+               LEFT JOIN b \
+                 ON (keys.a IS NOT DISTINCT FROM b.a) AND (keys.b IS NOT DISTINCT FROM b.b) \
+               LEFT JOIN c \
+                 ON (keys.a IS NOT DISTINCT FROM c.a) AND (keys.b IS NOT DISTINCT FROM c.b) \
+               ORDER BY k_a NULLS LAST, k_b NULLS LAST";
+
+    let logical = optimized_logical(&ctx, sql).await;
+    let logical_str = logical.display_indent().to_string();
+    let lifted_joins = logical_str.matches("Left Join: ").count();
+    assert_eq!(
+        lifted_joins, 3,
+        "expected all 3 LEFT JOINs to carry equi-keys, got:\n{logical_str}"
+    );
+    // None of the LEFT JOINs should still hang IS NOT DISTINCT FROM in `Filter:`.
+    assert!(
+        !logical_str.contains("Filter: keys.a IS NOT DISTINCT FROM"),
+        "rule failed to lift one of the chained joins, got:\n{logical_str}"
+    );
+
+    let physical = physical(&ctx, sql).await;
+    assert_eq!(
+        count_exec(physical.as_ref(), "HashJoinExec"),
+        3,
+        "expected 3 HashJoinExec in the chain, got plan:\n{}",
+        displayable(physical.as_ref()).indent(true)
+    );
+    assert_eq!(count_exec(physical.as_ref(), "NestedLoopJoinExec"), 0);
+
+    // The `(NULL,NULL)` driver row must match the `(NULL,NULL)` rows in A, B,
+    // and C — so all three `in_*` tags appear on the last row.
+    assert_plan_str(
+        run(&ctx, sql).await,
+        "\
++-----+-----+------+------+------+
+| k_a | k_b | in_a | in_b | in_c |
++-----+-----+------+------+------+
+| 1   | 10  | 1    |      |      |
+| 3   |     |      |      | 3    |
+|     | 20  |      | 2    |      |
+|     |     | 1    | 2    | 3    |
++-----+-----+------+------+------+",
+    );
+}
+
+/// Documents the conservative scope: when DF has already lifted an `=` key
+/// into ON, the rule keeps its hands off (flipping `null_equals_null` would
+/// silently make existing `=` keys null-safe). Mixed predicates fall back to
+/// a NestedLoopJoin filter for the `IS NOT DISTINCT FROM` side.
+#[tokio::test]
+async fn mixed_eq_and_is_not_distinct_from_is_left_alone() {
+    let ctx = ab_context();
+    let sql = "SELECT a.a AS a_a, a.b AS a_b, b.a AS b_a, b.b AS b_b \
+               FROM a LEFT JOIN b \
+               ON a.a = b.a AND (a.b IS NOT DISTINCT FROM b.b)";
+
+    let logical = optimized_logical(&ctx, sql).await;
+    let logical_str = logical.display_indent().to_string();
+    assert!(
+        logical_str.contains("Left Join: a.a = b.a")
+            && logical_str.contains("Filter: a.b IS NOT DISTINCT FROM b.b"),
+        "expected only `=` lifted and IS NOT DISTINCT FROM kept in filter, got:\n{logical_str}"
+    );
+
+    let physical = physical(&ctx, sql).await;
+    // The `=` key is hashable, so DF still chooses a HashJoinExec — with the
+    // IS NOT DISTINCT FROM clause attached as a residual filter on the join.
+    assert_eq!(count_exec(physical.as_ref(), "HashJoinExec"), 1);
+    assert_eq!(count_exec(physical.as_ref(), "NestedLoopJoinExec"), 0);
+}
diff --git a/rust/cubestore/cubestore/src/queryplanner/mod.rs b/rust/cubestore/cubestore/src/queryplanner/mod.rs
index 47bf8a9c0ec65..f2a41ac7d3b7c 100644
--- a/rust/cubestore/cubestore/src/queryplanner/mod.rs
+++ b/rust/cubestore/cubestore/src/queryplanner/mod.rs
@@ -23,6 +23,8 @@ pub use topk::MIN_TOPK_STREAM_ROWS;
 mod filter_by_key_range;
 pub mod info_schema;
 mod inline_aggregate;
+#[cfg(test)]
+mod is_not_distinct_from_join_test;
 pub mod merge_sort;
 pub mod metadata_cache;
 pub mod providers;
@@ -55,6 +57,7 @@ use crate::queryplanner::serialized_plan::SerializedPlan;
 use crate::queryplanner::topk::ClusterAggregateTopKLower;
 
 use crate::queryplanner::metadata_cache::MetadataCacheFactory;
+use crate::queryplanner::optimizations::is_not_distinct_from_join_keys::IsNotDistinctFromJoinKeysRule;
 use crate::queryplanner::optimizations::rolling_optimizer::RollingOptimizerRule;
 use crate::queryplanner::pretty_printers::{pp_plan_ext, PPOptions};
 use crate::queryplanner::udfs::{registerable_aggregate_udfs_iter, registerable_scalar_udfs_iter};
@@ -316,6 +319,7 @@ impl QueryPlannerImpl {
         // TODO upgrade DF: build SessionContexts consistently
         let state = Self::minimal_session_state_from_final_config(config)
             .with_optimizer_rule(Arc::new(RollingOptimizerRule {}))
+            .with_optimizer_rule(Arc::new(IsNotDistinctFromJoinKeysRule {}))
             .build();
 
         let context = SessionContext::new_with_state(state);
diff --git a/rust/cubestore/cubestore/src/queryplanner/optimizations/is_not_distinct_from_join_keys.rs b/rust/cubestore/cubestore/src/queryplanner/optimizations/is_not_distinct_from_join_keys.rs
new file mode 100644
index 0000000000000..ff69372085c5e
--- /dev/null
+++ b/rust/cubestore/cubestore/src/queryplanner/optimizations/is_not_distinct_from_join_keys.rs
@@ -0,0 +1,91 @@
+//! Fold `a IS NOT DISTINCT FROM b` join predicates into equi-keys with
+//! `null_equals_null = true` so the planner can pick a HashJoin instead of
+//! a NestedLoopJoin.
+//!
+//! Conservative scope: only fires when the `Join` has no existing equi-keys
+//! in `on`, so flipping `null_equals_null` cannot change semantics of any
+//! `=` predicates already extracted by DataFusion.
+
+use datafusion::common::tree_node::Transformed;
+use datafusion::logical_expr::expr_schema::ExprSchemable;
+use datafusion::logical_expr::utils::{
+    can_hash, find_valid_equijoin_key_pair, split_conjunction_owned,
+};
+use datafusion::logical_expr::{BinaryExpr, Expr, LogicalPlan, Operator};
+use datafusion::optimizer::optimizer::ApplyOrder;
+use datafusion::optimizer::{OptimizerConfig, OptimizerRule};
+
+#[derive(Debug)]
+pub struct IsNotDistinctFromJoinKeysRule {}
+
+impl OptimizerRule for IsNotDistinctFromJoinKeysRule {
+    fn name(&self) -> &str {
+        "is_not_distinct_from_join_keys"
+    }
+
+    fn apply_order(&self) -> Option<ApplyOrder> {
+        Some(ApplyOrder::TopDown)
+    }
+
+    fn supports_rewrite(&self) -> bool {
+        true
+    }
+
+    fn rewrite(
+        &self,
+        plan: LogicalPlan,
+        _config: &dyn OptimizerConfig,
+    ) -> datafusion::common::Result<Transformed<LogicalPlan>> {
+        let LogicalPlan::Join(mut join) = plan else {
+            return Ok(Transformed::no(plan));
+        };
+        if !join.on.is_empty() || join.filter.is_none() {
+            return Ok(Transformed::no(LogicalPlan::Join(join)));
+        }
+        // Safe: checked above. Keep the original around so we can put it back
+        // verbatim if nothing gets lifted — split_conjunction_owned + reduce
+        // would otherwise produce a structurally-different (but semantically
+        // equivalent) tree.
+        let filter_orig = join.filter.take().unwrap();
+
+        let left_schema = join.left.schema().as_ref();
+        let right_schema = join.right.schema().as_ref();
+
+        let mut new_on: Vec<(Expr, Expr)> = Vec::new();
+        let mut remaining: Vec<Expr> = Vec::new();
+
+        for expr in split_conjunction_owned(filter_orig.clone()) {
+            let lifted = match &expr {
+                Expr::BinaryExpr(BinaryExpr {
+                    left,
+                    op: Operator::IsNotDistinctFrom,
+                    right,
+                }) => find_valid_equijoin_key_pair(left, right, left_schema, right_schema)?
+                    .and_then(|(l, r)| {
+                        let l_ty = l.get_type(left_schema).ok()?;
+                        let r_ty = r.get_type(right_schema).ok()?;
+                        if can_hash(&l_ty) && can_hash(&r_ty) {
+                            Some((l, r))
+                        } else {
+                            None
+                        }
+                    }),
+                _ => None,
+            };
+            match lifted {
+                Some(pair) => new_on.push(pair),
+                None => remaining.push(expr),
+            }
+        }
+
+        if new_on.is_empty() {
+            join.filter = Some(filter_orig);
+            return Ok(Transformed::no(LogicalPlan::Join(join)));
+        }
+
+        join.on = new_on;
+        join.filter = remaining.into_iter().reduce(Expr::and);
+        join.null_equals_null = true;
+        Ok(Transformed::yes(LogicalPlan::Join(join)))
+    }
+}
diff --git a/rust/cubestore/cubestore/src/queryplanner/optimizations/mod.rs b/rust/cubestore/cubestore/src/queryplanner/optimizations/mod.rs
index 0359e64c476db..e4ee5eb698b3c 100644
--- a/rust/cubestore/cubestore/src/queryplanner/optimizations/mod.rs
+++ b/rust/cubestore/cubestore/src/queryplanner/optimizations/mod.rs
@@ -1,6 +1,7 @@
 mod check_memory;
 mod distributed_partial_aggregate;
 mod inline_aggregate_rewriter;
+pub mod is_not_distinct_from_join_keys;
 pub mod rewrite_plan;
 pub mod rolling_optimizer;
 mod trace_data_loaded;

From dede276fb4782d74df8e378ff5513696a7f15c75 Mon Sep 17 00:00:00 2001
From: Artyom Keydunov <artyom@cube.dev>
Date: Wed, 20 May 2026 15:11:48 -0700
Subject: [PATCH 4/4] docs: refresh intro video and Cube vs Cube Core
 positioning (#10926)

Update the workshop video (7ZQGGepDjUQ) on the docs intro page, the
README, and the playground Cube BI page. Remove the orphan
docs-mintlify/introduction.mdx duplicate (the canonical page is
/docs/introduction). Rewrite README and the docs intro to clearly
distinguish Cube Core (open-source semantic layer) from Cube
(commercial agentic analytics platform built on it).

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 README.md                                     | 37 +++++---
 docs-mintlify/docs/introduction.mdx           | 90 +++++++------------
 docs-mintlify/introduction.mdx                | 66 --------------
 .../src/pages/CubeBI/CubeBiPage.tsx           |  2 +-
 4 files changed, 59 insertions(+), 136 deletions(-)
 delete mode 100644 docs-mintlify/introduction.mdx

diff --git a/README.md b/README.md
index 86d8ba317aca6..736b2222f5e70 100644
--- a/README.md
+++ b/README.md
@@ -10,9 +10,9 @@
 [![GitHub Actions](https://github.com/cube-js/cube/workflows/Build/badge.svg)](https://github.com/cube-js/cube/actions?query=workflow%3ABuild+branch%3Amaster)
 [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fcube-js%2Fcube.js.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fcube-js%2Fcube.js?ref=badge_shield)
 
-__Cube Core is an open-source semantic layer.__ Cube Core can be used to build embedded analytics in your applications, create your own business intelligence tool or provide context about data to AI agents. Cube Core is headless and comes with multiple APIs for embedded analytics and BI: REST, GraphQL, and SQL.
+__Cube Core is the open-source semantic layer.__ Define metrics, dimensions, joins, and access rules once in code, then expose them through SQL, REST, and GraphQL APIs to anything downstream — BI tools, custom applications, or AI agents. Cube Core is headless: it doesn't ship a UI, so you can build the analytics experience that fits your product.
 
-If you are looking for a fully integrated platform, check out [Cube](https://cube.dev), a modern AI-first business intelligence platform. We use Cube Core to power it.
+Cube Core works with all SQL data sources, including cloud data warehouses like Snowflake, Databricks, and BigQuery; query engines like Presto and Amazon Athena; and application databases like Postgres. It has a built-in relational caching engine to provide sub-second latency and high concurrency for API requests.
 
 <img
   src="https://lgo0ecceic.ucarecd.net/418db1f9-7597-4e00-8c10-eba19fcac20f/"
@@ -24,19 +24,17 @@ If you are looking for a fully integrated platform, check out [Cube](https://cub
   <i>Learn more about connecting Cube to <a href="https://cube.dev/cube-core/getting-started/create-a-project?ref=github-readme" target="_blank">data sources</a> and <a href="https://cube.dev/docs/integrations?ref=github-readme" target="_blank">analytics & visualization tools</a>.</i>
 </p>
 
-Cube Core was designed to work with all SQL data sources, including cloud data warehouses like Snowflake, Databricks, and BigQuery; query engines like Presto and Amazon Athena; and application databases like Postgres. Cube Core has a built-in relational caching engine to provide sub-second latency and high concurrency for API requests.
-
 ## Why Cube Core?
 
-Every business intelligence tool relies on a semantic layer as its core engine—a critical component that defines metrics, dimensions, and business logic while abstracting the complexity of underlying data sources. However, most semantic layers are proprietary, tightly coupled to specific BI platforms, and cannot be reused across different applications.
+Every BI tool relies on a semantic layer as its core engine — the component that defines metrics, dimensions, and business logic and hides the complexity of the underlying data sources. Most semantic layers are proprietary, tightly coupled to a single BI platform, and can't be reused across other tools.
 
-Cube Core is an open-source project that aims to create an open, modern semantic layer that can be used to power any analytics applications and AI agents. By decoupling the semantic layer from specific tools and making it accessible through standard APIs, Cube Core enables organizations to define their metrics once and use them everywhere—from BI tools to embedded analytics to AI agents.
+Cube Core is an open, standalone semantic layer that any analytics application or AI agent can consume through standard APIs. Define your metrics once and use them everywhere — internal BI, embedded analytics, AI agents — without re-implementing the model in each place.
 
-## Getting Started 🚀
+## Getting Started
 
-You can get started with Cube locally or self-host it with [Docker](https://www.docker.com/).
+You can run Cube Core locally or self-host it with [Docker](https://www.docker.com/).
 
-Once Docker is installed, in a new folder for your project, run the following command:
+Once Docker is installed, in a new folder for your project, run:
 
 ```bash
 docker run -p 4000:4000 \
@@ -46,15 +44,28 @@ docker run -p 4000:4000 \
   cubejs/cube
 ```
 
-Then, open http://localhost:4000 in your browser to continue setup.
+Then open http://localhost:4000 in your browser to continue setup.
 
 For a step-by-step guide, [see the docs](https://cube.dev/cube-core/getting-started/create-a-project?ref=github-readme).
 
-### Cube — Complete Modern BI Tool from Cube Core Creators
+## Cube Core vs. Cube
+
+[Cube](https://cube.dev?ref=github-readme) is our commercial product — an agentic analytics platform built on Cube Core. Same semantic layer underneath, plus the rest of what makes it a full BI platform: Analytics Chat, workbooks and dashboards, embedded analytics surfaces, managed deployment, RBAC, multi-tenancy, and integrations with Tableau, Power BI, Excel, and Google Sheets.
+
+The data model is fully compatible both ways: a model you build in Cube Core runs unchanged in Cube, and vice versa. Cube Core stays open-source and is what we run inside Cube ourselves.
+
+- **Use Cube Core** when you want to own the stack — a custom BI experience, deeply integrated embedded analytics, or AI agents that need a governed semantic foundation.
+- **Use Cube** when you want a managed, full-featured BI platform out of the box — internal analytics or customer-facing embedded analytics without building the surrounding platform yourself.
+
+For more on how we think about the split, see [The Future of Cube Core and Cube](https://cube.dev/blog/cube-core-and-cube).
+
+For a tour of what's in Cube today, watch the workshop:
 
-[Cube](https://cube.dev?ref=github-readme) is a complete modern agentic analytics platform built on Cube Core. It provides a fully integrated solution with a user-friendly interface, advanced analytics capabilities, and managed infrastructure.
+<a href="https://www.youtube.com/watch?v=7ZQGGepDjUQ" target="_blank">
+  <img src="https://img.youtube.com/vi/7ZQGGepDjUQ/maxresdefault.jpg" alt="Cube agentic analytics workshop on YouTube" width="600">
+</a>
 
-<a href="https://cubecloud.dev/auth/signup?ref=github-readme"><img src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/f1f1eac0-0b44-4c47-936e-33b5c06eedf0.png" alt="Get started now" width="200px"></a>
+Or [try Cube for free](https://cubecloud.dev/auth/signup?ref=github-readme).
 
 ## Resources
 
diff --git a/docs-mintlify/docs/introduction.mdx b/docs-mintlify/docs/introduction.mdx
index c05898e02631d..2a60cc0e5227e 100644
--- a/docs-mintlify/docs/introduction.mdx
+++ b/docs-mintlify/docs/introduction.mdx
@@ -1,40 +1,41 @@
 ---
 title: Introduction
-description: Cube is the agentic analytics platform for business intelligence and embedded analytics, powered by the open-source semantic layer.
+description: Cube is the agentic analytics platform for business intelligence and embedded analytics, built on an open-source semantic layer.
 hideTableOfContents: true
 ---
 
-The AI analytics platform that combines self-serve conversational analytics, governed data modeling, and embedded analytics — all powered by an open-source semantic layer.
+Cube is the agentic analytics platform built on a semantic layer. One product, two primary use cases: internal business intelligence and embedded analytics.
 
 <iframe
   width="100%"
   height="400"
-  src="https://www.youtube.com/embed/gvDy37p7AZ0"
-  title="YouTube video"
+  src="https://www.youtube.com/embed/7ZQGGepDjUQ"
+  title="Cube: The Agentic Analytics Platform. Full Demo"
   frameBorder="0"
   allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
   allowFullScreen
 />
 
-Cube is an AI analytics platform for the whole organization — built to be used by both humans and AI agents. It combines self-serve conversational analytics, governed data modeling, and embedded analytics experiences, all on top of an open-source semantic layer. It empowers different personas across your organization:
+For internal BI, data teams and business users explore data with workbooks, dashboards, and Analytics Chat — natural-language analysis grounded in a governed data model. For embedded analytics, software companies ship the same surfaces, and the underlying APIs, inside their own products to deliver customer-facing experiences.
 
-- **Data Engineers** can quickly curate data models with AI assistance, accelerating development and reducing time-to-insight for the whole organization
-- **Data Analysts** can perform deep analysis with AI assistance, getting trusted answers without writing ad-hoc SQL
-- **Business Users** can self-serve with natural language questions, workbooks, and dashboards — no tickets to the data team required
+Cube is built for both humans and AI agents:
+
+- **Data engineers** build and maintain semantic models in code, with AI assistance.
+- **Data analysts** explore deeply and get trusted answers without writing ad-hoc SQL.
+- **Business users** ask questions in natural language and get answers grounded in the same data model the data team owns.
+- **AI agents** like Claude, ChatGPT, or your own connect through the MCP server or Chat API to get analytics answers grounded in the same governed data model.
 
 ## How is Cube different?
 
-At the foundation of Cube's agentic analytics platform is an [open-source semantic layer](https://github.com/cube-js/cube) — the shared context that enables both AI agents and humans to work with trusted, consistent data.
+At the foundation of Cube is an [open-source semantic layer](https://github.com/cube-js/cube) — **Cube Core** — that provides the shared context every consumer works from. It centralizes metric definitions, joins, access rules, and caching upstream of every BI tool, application, and AI agent that queries the data. The same Cube Core that powers Cube is what we maintain as open-source; data models port unchanged between the two.
 
-The semantic layer provides the governed data foundation that makes agentic analytics possible. It organizes data from your cloud data warehouses into centralized, consistent definitions that AI agents can reliably query, explore, and reason about. Without a semantic layer, AI agents would struggle with inconsistent metrics, scattered business logic, and ungoverned data access—making their outputs unreliable and potentially dangerous.
+The semantic layer is what makes AI useful. Without one, agents writing SQL against a warehouse end up with inconsistent metrics and ungoverned access — numbers that don't match how your business defines them. With one, agents get a stable, governed surface to reason over.
 
 ### Semantic SQL
 
-Unlike other tools, Cube AI agents don't query the data warehouse directly. Instead, they query the semantic layer using Semantic SQL, creating a trusted proxy architecture. The semantic layer runtime acts as guardrails between AI agents and your warehouse—all queries must pass through this deterministic runtime, which validates every request and prevents incorrect queries from reaching your data.
-
-Semantic SQL extends Postgres-compatible SQL with the MEASURE function. This architecture lets AI leverage the full power of SQL to build ad-hoc derived calculations on top of existing semantic model calculations, combining flexibility with governance.
+Cube AI agents don't query the warehouse directly. They query the semantic layer using Semantic SQL — a Postgres-compatible interface that extends SQL with the `MEASURE` function. Every query passes through the semantic layer runtime, where it's validated against the data model and has access policies applied deterministically before reaching the warehouse.
 
-Security policies are enforced deterministically at the semantic layer runtime, ensuring consistent access control across all queries.
+Semantic SQL gives agents the full expressiveness of SQL to build ad-hoc derived calculations on top of governed metrics — flexibility on a stable foundation, instead of one or the other.
 
 <Frame>
   <img src="https://lgo0ecceic.ucarecd.net/97dd04e5-f534-424e-8d6b-e6e0c19fd95f/" />
@@ -42,64 +43,41 @@ Security policies are enforced deterministically at the semantic layer runtime,
 
 ### Semantic layer architecture
 
-#### Code-first
-
-A code-first approach is essential for both traditional data engineering and agentic analytics. Managing data models, configurations, and policies as code enables the same proven practices that power modern software development: version control for collaboration and code reviews, automated testing and documentation, and established patterns for reusability and maintainability.
+The semantic layer is built on four pillars: data modeling, access control, caching, and APIs.
 
-For agentic analytics specifically, a code-first semantic layer creates new possibilities. AI agents can help curate and maintain data models themselves, accelerating development while maintaining quality through git workflows. The structured, version-controlled nature of code makes it easier for agents to understand changes, suggest improvements, and even implement modifications autonomously.
-
-Everything within Cube—from configurations to data models to access control policies—is managed through code. This foundation enables both human data engineers and AI agents to collaborate on building and maintaining the semantic layer that powers agentic analytics.
-
-The semantic layer that powers Cube's agentic analytics platform is built on four essential pillars: data modeling, access control, caching, and APIs. Each pillar plays a critical role in enabling AI agents and users to work with data reliably, securely, and efficiently.
-
-#### Data Modeling
+#### Code-first
 
-**The data model provides the knowledge graph that AI agents use to understand your business.** It centralizes metric definitions, entity relationships, and business logic upstream from all consumption tools—whether those are AI agents, BI tools, or custom applications. This centralization is critical for agentic analytics: AI agents need a structured understanding of what metrics mean, how entities relate, and what calculations are valid.
+Everything in Cube — data models, configurations, access control policies — is managed as code. That brings version control, code review, CI, and isolated environments to the semantic layer, the same way modern software teams already manage application code.
 
-When an AI agent analyzes sales performance or answers questions about customer behavior, it relies on the semantic layer's data model to understand that "revenue" is calculated consistently, that customers have orders, and that orders contain line items. This structured knowledge enables agents to generate reliable insights and navigate complex data relationships autonomously.
+Code-first also makes AI assistance practical: agents can read, propose, and edit the model through normal git workflows. Humans review the change before it lands.
 
-**Cube's data model is code-first.** Data teams define data models with YAML or JavaScript code, managed through version control systems. This enables AI-assisted development where agents can help curate and maintain the semantic layer itself, accelerating model development while maintaining quality through git workflows and multiple isolated environments.
+#### Data modeling
 
-**Cube's data model is dataset-centric**, inspired by and expanding upon dimensional modeling. You work with two types of objects:
+The data model is the knowledge graph the platform — and any AI agent — uses to understand your business. It defines metrics, entities, joins, and how they relate, upstream of any consumer.
 
-**Cubes** represent business entities such as customers, line items, and orders. They define all calculations within measures and dimensions, as well as relationships between entities. These relationships form the knowledge graph that AI agents traverse when exploring data and generating insights.
+Cube's model is **dataset-centric**, expanding on dimensional modeling. You work with two object types:
 
-**Views** sit on top of the data graph of cubes, creating facades that data consumers interact with. Think of views as the final data products for AI agents, BI users, and applications. Views select measures and dimensions from connected cubes and present them as unified datasets, providing AI agents with the right context and scope for specific analytical tasks.
+- **Cubes** represent business entities — customers, orders, line items. They define measures, dimensions, and joins between entities.
+- **Views** sit on top of cubes and present curated, query-ready datasets. Views are what data consumers — humans and agents — interact with.
 
-#### Access Control
+Models are written in YAML or JavaScript and managed in version control.
 
-**Access control ensures that AI agents respect the same data security policies as human users.** This is critical for agentic analytics: when AI agents autonomously query and analyze data, they must enforce the same governance rules that apply to human users—whether that's row-level security, column-level restrictions, or data masking.
+#### Access control
 
-By centralizing access control in the semantic layer, you ensure that all data consumption—whether by AI agents, BI tools, or custom applications—goes through a single governed checkpoint. This provides comprehensive oversight and prevents agents from inadvertently exposing sensitive data or violating security policies.
+Access control runs at the semantic layer, so the same policies apply to every consumer: AI agents, BI tools, embedded applications. Define the rule once; it's enforced everywhere.
 
-Cube's code-first approach enables data teams to **define access control policies with Python or JavaScript**, ranging from simple row-level access rules to completely custom data models per tenant backed by different data sources. These policies apply uniformly to all consumers of the semantic layer, ensuring AI agents operate within the same security boundaries as human users.
+Policies are code (Python or JavaScript) and range from row-level rules to fully tenant-aware models backed by different data sources.
 
 #### Caching
 
-**Caching enables AI agents to deliver fast, interactive experiences without overwhelming your data infrastructure.** For agentic analytics to be effective, AI agents must respond quickly to user questions, iteratively explore data, and generate insights in real-time. Without caching, every agent query would hit your data warehouse directly, creating latency issues and potentially significant costs.
+Cube's caching is built on **pre-aggregations** — rollup tables declared in the data model and refreshed in the background, stored in Cube Store (Cube's distributed caching engine).
 
-The semantic layer acts as a performance buffer between AI agents and your data sources. Through intelligent caching, it ensures agents can work interactively while protecting your cloud data warehouse from unnecessary and redundant load.
-
-Cube implements caching through an **aggregate awareness framework called pre-aggregations.** Data teams define pre-aggregates in the data model as rollup tables, including measures and dimensions. Cube builds and refreshes these pre-aggregates in the background by querying your cloud data warehouse and storing results in Cube Store, Cube's purpose-built caching engine backed by distributed file storage such as S3. Pre-aggregations can be refreshed on schedule or as part of workflow orchestration.
-
-When an AI agent sends a query to Cube, the aggregate awareness engine determines if an existing and fresh pre-aggregate can serve that query. This significantly accelerates agent responses and reduces both latency and data warehouse costs—essential for enabling the iterative, exploratory workflows that characterize agentic analytics.
+When a query comes in, Cube's aggregate awareness engine routes it to a matching pre-aggregation when one exists. This is what keeps interactive workflows fast and warehouse costs predictable.
 
 #### APIs
 
-**APIs enable AI agents, applications, and tools to interact with the semantic layer through standard protocols.** For agentic analytics to work across diverse use cases—from AI-powered workbooks to embedded analytics to traditional BI—the semantic layer must provide universal interoperability. AI agents need to query data, introspect the data model, and integrate with other systems without requiring custom integrations for every tool or framework.
-
-Rather than inventing proprietary protocols, Cube implements widely adopted standards: **REST (JSON), GraphQL, and SQL.**
-
-**REST (JSON) and GraphQL** provide modern API interfaces for building custom applications and enabling programmatic access. These APIs power agentic workflows, allowing AI agents to query data, retrieve results, and build interactive experiences.
-
-**SQL** is universally adopted across the data stack. Every BI tool, visualization platform, and data application can query a SQL data source. Cube implements Postgres-compatible SQL and extends it to support semantic layer concepts like measures—special types that know how to evaluate themselves based on data model definitions. Any tool that can connect to Postgres or Redshift can connect to Cube, making the semantic layer accessible to both AI agents and traditional analytics tools.
-
-**Data model introspection through the meta API** is essential for agentic analytics. It enables AI agents to discover available metrics, understand entity relationships, and determine valid queries—providing the context agents need to navigate the semantic layer autonomously. This same introspection capability allows BI tools to automatically map to data model objects and helps applications build dynamic interfaces.
-
+The semantic layer exposes standard APIs so any consumer can plug in:
 
-[ref-workbooks]: /docs/workspace/workbooks
-[ref-embedding]: /reference/embedding
-[ref-chat-api]: /reference/chat-api
-[ref-mcp-server]: /docs/integrations/mcp-server
-[ref-agent-rules]: /admin/ai/rules
-[ref-agent-memories]: /admin/ai/memory-isolation
\ No newline at end of file
+- **SQL** — Postgres-compatible, with `MEASURE` and related extensions. Any tool that talks to Postgres or Redshift can talk to Cube.
+- **REST (JSON)** and **GraphQL** — for custom applications and programmatic access.
+- **Meta API** — model introspection. Lets AI agents discover what's queryable, and lets BI tools auto-map to the data model.
diff --git a/docs-mintlify/introduction.mdx b/docs-mintlify/introduction.mdx
deleted file mode 100644
index 769389c12f135..0000000000000
--- a/docs-mintlify/introduction.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Introduction
-description: Cube is the business intelligence platform powered by the open-source semantic layer.
----
-
- Introduction
-
-Cube is the business intelligence platform powered by the open-source semantic layer.
-
-Cube uses AI agents to build data models and enable data consumers to perform analysis. Use AI to quickly build semantic layer and fully control the analytics context.
-
-<iframe
-  width="100%"
-  height="400"
-  src="https://www.youtube.com/embed/gvDy37p7AZ0"
-  title="Cube Introduction"
-  frameBorder="0"
-  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
-  allowFullScreen
-/>
-
-Cube is a new generation of a business intelligence and embedded analytics platform built to be used by both humans and AI agents. It empowers different personas across your organization:
-
-- **Data Engineers** can quickly curate data models with AI assistance, accelerating the development and maintenance of semantic layers
-- **Data Analysts** can perform deep analysis with AI assistance, diving into complex data relationships and patterns
-- **Business Users** benefit from workbooks and dashboards that Cube can automatically build and maintain
-
-## How is Cube different?
-
-At the foundation of Cube's agentic analytics platform is an [open-source semantic layer](https://github.com/cube-js/cube) — the critical infrastructure that enables both AI agents and humans to work with trusted, consistent data.
-
-### Semantic SQL
-
-Unlike other tools, Cube AI agents don't query the data warehouse directly. Instead, they query the semantic layer using Semantic SQL, creating a trusted proxy architecture.
-
-<img
-  src="https://lgo0ecceic.ucarecd.net/97dd04e5-f534-424e-8d6b-e6e0c19fd95f/"
-  alt="Semantic SQL architecture"
-/>
-
-### Semantic layer architecture
-
-#### Code-first
-
-A code-first approach is essential for both traditional data engineering and agentic analytics. Managing data models, configurations, and policies as code enables the same proven practices that power modern software development.
-
-Everything within Cube — from configurations to data models to access control policies — is managed through code.
-
-#### Data Modeling
-
-The data model provides the knowledge graph that AI agents use to understand your business. Cube's data model is **code-first** and **dataset-centric**, inspired by dimensional modeling. You work with two types of objects:
-
-- **Cubes** represent business entities such as customers, line items, and orders
-- **Views** sit on top of the data graph of cubes, creating facades that data consumers interact with
-
-#### Access Control
-
-Access control ensures that AI agents respect the same data security policies as human users. Cube's code-first approach enables data teams to define access control policies with Python or JavaScript.
-
-#### Caching
-
-Caching enables AI agents to deliver fast, interactive experiences without overwhelming your data infrastructure. Cube implements caching through **pre-aggregations** — rollup tables that accelerate query responses and reduce data warehouse costs.
-
-#### APIs
-
-APIs enable AI agents, applications, and tools to interact with the semantic layer through standard protocols: **REST (JSON)**, **GraphQL**, and **SQL**.
diff --git a/packages/cubejs-playground/src/pages/CubeBI/CubeBiPage.tsx b/packages/cubejs-playground/src/pages/CubeBI/CubeBiPage.tsx
index 5a89e81d6c38f..04c0052fd5087 100644
--- a/packages/cubejs-playground/src/pages/CubeBI/CubeBiPage.tsx
+++ b/packages/cubejs-playground/src/pages/CubeBI/CubeBiPage.tsx
@@ -58,7 +58,7 @@ export function CubeBiPage() {
       </StyledHeader>
       <VideoContainer>
         <iframe
-          src="https://www.youtube.com/embed/n-U1FvHqE2Q?start=59"
+          src="https://www.youtube.com/embed/7ZQGGepDjUQ?start=1289"
           title="Cube BI Video"
           allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
           allowFullScreen