feat(landing): add comparison pages

apps/landing/src/content.config.ts

@@ -4,6 +4,7 @@ import { glob } from "astro/loaders";
 import { defineCollection } from "astro:content";
 
 import { createBlogPostContentSchema } from "@/features/blog/schema";
+import { createComparisonContentSchema } from "@/features/compare/schema";
 
 const blog = defineCollection({
   loader: glob({
@@ -14,9 +15,18 @@ const blog = defineCollection({
   schema: createBlogPostContentSchema,
 });
 
+const compare = defineCollection({
+  loader: glob({
+    base: "./src/content/compare",
+    pattern: "**/*.mdx",
+    retainBody: true,
+  }),
+  schema: createComparisonContentSchema,
+});
+
 const docs = defineCollection({
   loader: docsLoader(),
   schema: docsSchema(),
 });
 
-export const collections = { blog, docs };
+export const collections = { blog, compare, docs };

apps/landing/src/content/compare/onequery-vs-bi-chatbot.mdx

@@ -0,0 +1,73 @@
+---
+order: 4
+title: "OneQuery vs BI Chatbot | Operational Agent Access"
+metaDescription: "Compare OneQuery with BI chatbots for AI agent data access. Use dashboards for business answers and governed sources for operational agents."
+alternativeName: "BI chatbot"
+category: "Analytics versus operations"
+eyebrow: "OneQuery vs BI chatbot"
+summary: "BI chatbots make analytics more accessible. OneQuery makes production source access safer for agents that do operational work."
+answer: "Use OneQuery instead of a BI chatbot when the agent needs operational production context, not just dashboard-backed analytics answers. BI chatbots are best for business metrics; OneQuery is built for governed source access by coding, incident, and internal automation agents."
+heroSignals:
+  - "BI for metrics"
+  - "OneQuery for source context"
+  - "Separate analytics from agent access"
+keywords:
+  - "OneQuery vs BI chatbot"
+  - "AI agent data access vs BI chatbot"
+  - "operational data access for agents"
+  - "business intelligence chatbot"
+  - "production context for coding agents"
+criteria:
+  - factor: "Primary context"
+    oneQuery: "Agents can query approved databases and provider APIs for task-specific production context."
+    alternative: "Answers usually come from dashboards, saved questions, models, or a BI semantic layer."
+  - factor: "Primary user"
+    oneQuery: "Designed for agent workflows running through CLI, gateway, and source commands."
+    alternative: "Designed for humans asking business questions in a BI workspace or embedded analytics surface."
+  - factor: "Governance model"
+    oneQuery: "Governance is tied to source credentials, query validation, limits, and audit history."
+    alternative: "Governance is tied to BI permissions, curated datasets, and metric definitions."
+  - factor: "Best answer shape"
+    oneQuery: "Best for retrieving narrow operational evidence that an agent can use to debug, triage, or automate."
+    alternative: "Great for explaining trends, charts, cohorts, and reports."
+  - factor: "Operational fit"
+    oneQuery: "Can connect production databases, warehouses, observability tools, product analytics, and developer systems."
+    alternative: "May not expose the low-level source, incident, or developer-tool context an engineering agent needs."
+oneQueryBestFor:
+  - "Coding agents investigating errors, logs, database state, or customer-impacting incidents."
+  - "Internal automations that need source-specific evidence, not only chart summaries."
+  - "Teams that need source execution audit history outside a BI workspace."
+alternativeBestFor:
+  - "Business users asking metric, dashboard, and report questions."
+  - "A governed semantic layer where terms like revenue, churn, and active user already have company-approved definitions."
+  - "Recurring executive or go-to-market workflows that belong in dashboards and scheduled reports."
+migrationSteps:
+  - "Keep dashboard and metric questions routed to the BI chatbot."
+  - "Identify operational agent workflows that need raw source context or developer-tool data."
+  - "Connect those sources to OneQuery with read-only or least-privilege credentials."
+  - "Document when agents should use BI answers versus OneQuery source execution."
+faqs:
+  - question: "Does OneQuery replace a BI chatbot?"
+    answer: "Usually no. A BI chatbot and OneQuery solve different layers. Use the BI chatbot for business analytics questions and OneQuery for governed source access in engineering and automation workflows."
+  - question: "How do I choose between the two?"
+    answer: "Choose a BI chatbot when the answer should come from approved metrics, dashboards, reports, or a semantic model. Choose OneQuery when an agent needs bounded access to production sources during an operational task."
+  - question: "Can BI and OneQuery coexist?"
+    answer: "Yes. Teams can keep BI as the business analytics interface and use OneQuery as the access layer for coding agents, incident agents, and internal tools that need broader source context."
+references:
+  - label: "OneQuery connectors"
+    href: "/connectors/"
+    description: "OneQuery docs on supported databases, warehouses, analytics systems, and developer tools."
+  - label: "Query boundaries"
+    href: "/docs/concepts/query-boundaries/"
+    description: "OneQuery docs on what source requests are allowed to do."
+---
+
+## Analytics answers and operational context are different jobs
+
+BI chatbots are strongest when the company has already curated the data shape: metrics, dashboards, models, reports, and common business definitions. That is the right interface for many business questions.
+
+Operational agents often need a different kind of evidence. They may need a narrow production query, a recent error from an observability tool, a linked issue, or a support-system record. OneQuery gives those workflows a source boundary without turning the BI layer into the agent runtime.
+
+## Recommended rollout
+
+Write down which questions should stay in BI. Route the remaining operational workflows through OneQuery sources, starting with incident or debugging tasks where audit history and small result windows matter.

apps/landing/src/content/compare/onequery-vs-datagrip-for-ai-agents.mdx

@@ -0,0 +1,76 @@
+---
+order: 6
+title: "OneQuery vs DataGrip for AI Agents | Safe Database Access"
+metaDescription: "Compare OneQuery with DataGrip for AI agents. Keep DataGrip for human SQL work and OneQuery for bounded agent source access."
+alternativeName: "DataGrip for AI agents"
+category: "IDE versus agent access layer"
+eyebrow: "OneQuery vs DataGrip for agents"
+summary: "DataGrip is excellent for trusted humans writing SQL. OneQuery is the safer path when the caller is an agent that should not hold database connection details."
+answer: "Use OneQuery instead of DataGrip for AI agents when the user is an autonomous agent rather than a human SQL operator. DataGrip is a database IDE for people; OneQuery is a governed source access layer that lets agents query approved data without receiving database connection details."
+heroSignals:
+  - "DataGrip for humans"
+  - "OneQuery for agents"
+  - "No IDE credentials in runtime"
+keywords:
+  - "OneQuery vs DataGrip for AI agents"
+  - "DataGrip AI agent alternative"
+  - "AI agent SQL access"
+  - "database IDE versus agent access layer"
+  - "safe agent database queries"
+criteria:
+  - factor: "Primary user"
+    oneQuery: "OneQuery is built around agent and CLI workflows that need controlled source access."
+    alternative: "DataGrip is built around human database work: data sources, query consoles, SQL files, schema browsing, and editor assistance."
+  - factor: "Connection details"
+    oneQuery: "The agent receives a source identifier while OneQuery stores and uses the source credential server-side."
+    alternative: "The IDE needs connection details such as host, port, password, and related settings for each data source."
+  - factor: "Execution judgment"
+    oneQuery: "OneQuery applies deterministic boundaries before agent-generated SQL reaches the source."
+    alternative: "A human chooses which SQL to run and can inspect the database state through the IDE."
+  - factor: "Audit model"
+    oneQuery: "Source requests are recorded as agent access events with actor, source, operation, outcome, and time."
+    alternative: "IDE history and database logs may help, but they are not an agent access control plane."
+  - factor: "Best fit"
+    oneQuery: "Best for giving coding agents narrow, repeatable, auditable access to production context."
+    alternative: "Excellent for interactive development, schema exploration, and SQL authoring by trusted users."
+oneQueryBestFor:
+  - "AI coding agents that need database evidence during production debugging."
+  - "Teams that want humans to keep powerful IDEs while agents get narrower source interfaces."
+  - "Workflows where query validation and audit history matter more than IDE ergonomics."
+alternativeBestFor:
+  - "Human developers writing, debugging, and organizing SQL in a full database IDE."
+  - "Schema browsing, query consoles, data editor workflows, and database object inspection."
+  - "A trusted operator session where the person using the tool should hold the database connection details."
+migrationSteps:
+  - "Keep human SQL authoring and schema exploration in DataGrip."
+  - "Create a scoped OneQuery source for the production data the agent can inspect."
+  - "Remove DataGrip connection details, passwords, and DSNs from the agent environment."
+  - "Use OneQuery audit history to review the agent's production source activity."
+faqs:
+  - question: "Does OneQuery replace DataGrip?"
+    answer: "No. Keep DataGrip for human database work. Use OneQuery for agent workflows where the database credential should stay outside the agent runtime."
+  - question: "Why not give an agent a DataGrip connection?"
+    answer: "Giving an agent an IDE connection profile recreates the direct-credential problem. OneQuery lets the agent request data through a bounded interface without owning the connection details."
+  - question: "How can developers use DataGrip and OneQuery together?"
+    answer: "A developer can use DataGrip to design or verify a query, then give the agent a OneQuery source and a narrow command pattern for repeatable production-safe runs."
+references:
+  - label: "DataGrip data sources"
+    href: "https://www.jetbrains.com/help/datagrip/managing-data-sources.html"
+    description: "JetBrains documentation on DataGrip data sources and supported databases."
+  - label: "DataGrip database connections"
+    href: "https://www.jetbrains.com/help/datagrip/connecting-to-a-database.html"
+    description: "JetBrains documentation on DataGrip database connection details and sessions."
+  - label: "DataGrip code editor"
+    href: "https://www.jetbrains.com/help/datagrip/code-editor.html"
+    description: "JetBrains documentation on DataGrip SQL query editing and consoles."
+---
+
+## Keep the IDE for humans
+
+DataGrip is a strong human database IDE. It helps trusted operators manage data sources, write SQL, inspect schemas, and work interactively with query consoles.
+
+That is a different job from giving an autonomous agent production context. An agent does not need the full IDE connection profile. It needs a narrow way to ask a source-specific question and receive a bounded answer.
+
+## Recommended rollout
+
+Keep DataGrip in the human workflow for query design and review. Give the agent a OneQuery source identifier and remove IDE connection details from the agent runtime.

apps/landing/src/content/compare/onequery-vs-direct-database-credentials.mdx

@@ -0,0 +1,73 @@
+---
+order: 1
+title: "OneQuery vs Direct Database Credentials | Safe AI Agent Access"
+metaDescription: "Compare OneQuery with direct database credentials for AI agents. See when governed source access beats handing agents raw passwords or DSNs."
+alternativeName: "direct database credentials"
+category: "Credential strategy"
+eyebrow: "OneQuery vs raw database access"
+summary: "Direct database credentials can be fast for a human, but they make the agent runtime the security boundary. OneQuery moves that boundary into a governed execution layer."
+answer: "Use OneQuery instead of direct database credentials when an AI agent needs production context. Direct credentials put the password, DSN, or cloud token inside the agent runtime; OneQuery keeps the credential server-side and gives the agent a bounded source interface."
+heroSignals:
+  - "Credential stays centralized"
+  - "Read-only query boundary"
+  - "Auditable agent access"
+keywords:
+  - "OneQuery vs direct database credentials"
+  - "AI agent database credentials"
+  - "safe production database access for agents"
+  - "centralized credentials"
+  - "read-only query validation"
+criteria:
+  - factor: "Credential exposure"
+    oneQuery: "Credentials stay in OneQuery source configuration and the agent receives only a source identifier and command surface."
+    alternative: "The agent receives a password, DSN, IAM credential, or environment variable that can reach the database."
+  - factor: "Query boundary"
+    oneQuery: "SQL requests pass through read-only validation, single-statement enforcement, limits, and source-specific execution controls."
+    alternative: "Read-only behavior depends on the database role and on the agent choosing safe SQL."
+  - factor: "Audit trail"
+    oneQuery: "Each request records actor, source, operation, outcome, and time in a purpose-built access history."
+    alternative: "Teams often reconstruct agent activity from shell history, database logs, or model transcripts."
+  - factor: "Rotation"
+    oneQuery: "Rotate the source credential centrally while keeping the agent workflow pointed at the same approved source."
+    alternative: "Credential rotation requires updating every place where the agent or tool runtime received the secret."
+  - factor: "Failure mode"
+    oneQuery: "Denied writes, oversized responses, missing permissions, and broad queries become explicit blocked states."
+    alternative: "A prompt rule can tell the agent to be careful, but it cannot reduce the authority attached to the credential."
+oneQueryBestFor:
+  - "Production debugging where agents need real database context but should not hold secrets."
+  - "Teams that need an audit trail for agent data access."
+  - "Workflows where prompt rules are not enough to enforce read-only behavior."
+alternativeBestFor:
+  - "A local development database that contains no production data."
+  - "A one-off human DBA session where the operator already owns the credential."
+  - "A throwaway read-only role that can be revoked immediately after testing."
+migrationSteps:
+  - "Create a read-only upstream database role for the data the agent is allowed to inspect."
+  - "Connect that role as a named OneQuery source."
+  - "Replace the agent's DSN or password with the OneQuery source identifier and command pattern."
+  - "Run a small production debugging workflow and review the resulting audit history."
+faqs:
+  - question: "When are direct database credentials acceptable for an AI agent?"
+    answer: "Use a direct credential only for low-risk human workflows or isolated test data. For production data, the safer pattern is to give the agent a controlled source interface while the credential stays outside the model runtime."
+  - question: "Does OneQuery replace database-level permissions?"
+    answer: "OneQuery is not a replacement for scoped database roles. It works best with read-only upstream roles, then adds source resolution, validation, limits, and audit records around the agent workflow."
+  - question: "How do I move from direct credentials to OneQuery?"
+    answer: "Point the agent at a OneQuery source identifier, remove the database secret from the agent environment, and review the first runs in audit history before adding more sources."
+references:
+  - label: "Governed access"
+    href: "/docs/concepts/governed-access/"
+    description: "OneQuery docs on keeping raw provider credentials outside the agent runtime."
+  - label: "Query boundaries"
+    href: "/docs/concepts/query-boundaries/"
+    description: "OneQuery docs on read-only validation, single-statement execution, limits, and blocked requests."
+---
+
+## The practical difference
+
+A direct credential turns the agent environment into the control plane. If the credential can reach production, the agent can try to use that authority whenever its plan points there.
+
+OneQuery keeps the useful part of the workflow: the agent can still ask focused database questions. The difference is that the source, credential, validation, limits, and audit record stay outside the prompt and outside the shell environment.
+
+## Recommended rollout
+
+Start with the smallest read-only source that answers a real debugging question. Remove the raw DSN from the agent setup, give the agent the OneQuery source identifier, and treat denied or truncated requests as normal feedback instead of reasons to broaden the credential.