All the BI. No BS.

The service caches table and column metadata, honors any configured schema or table scope, and sends question-relevant schema context to the AI. Without a configured scope, the connected account’s accessible schema defines the boundary. This is useful context for SQL generation, not a governed or full semantic layer with centrally defined metrics, lineage, and business definitions.

Yes. The service persists chat history, and teams can reuse approved SQL through a saved-query library with folders and templates. Saved queries can feed reusable dashboards and reports. Chat visibility is more restricted than shared workspace assets and follows the product access rules.

Shared workspaces let members use the query library, dashboards, and reports subject to their roles and datasource access. Git or dbt sync is not available, so these assets are managed inside the product rather than through an external analytics repository.

Generated SQL is parsed as a single read-only statement and checked against any configured schema scope or table scope before connector execution. Some execution failures trigger a bounded retry or schema refresh. AI-generated SQL and answers can still be incomplete or wrong, and there is no calibrated confidence score for generated SQL or answers, so review important results before relying on them.

The connector defaults are a 15-second statement timeout, a 50-row page size with a maximum of 2,000 rows per page, and 20,000 characters of SQL; deployments can configure these limits. The product has no BigQuery bytes-scanned protection because BigQuery is not a supported connector.

Depending on deployment configuration, prompts, schema context, and query-result context may be processed by providers such as OpenAI, Groq, or similar providers. The legal policy does not permit customer data to be used for AI-provider training without a written agreement or a clear, explicit opt-in. Privacy Policy

When a query fails because a table or column appears to be missing, the service can refresh the cached schema and retry with the updated context. If the refresh is unavailable, fails, or still cannot produce a safe query, the remaining failure is shown instead of being hidden.

The product can work with legacy or inconsistently named schemas, but ambiguous naming still needs analyst review. It does not redesign the database or create indexes. Connector execution remains read-only, and complex analysis can still place load on the source. Use a read-only replica or reporting database when production isolation is important.

No. A duplicate or read-only replica is not required, but it can isolate analytical load from a busy production system. Whether you need one depends on source-system capacity, query complexity, and your operational risk tolerance.

The product combines an AI model with your configured datasource scope, cached schema context, read-only SQL execution, and reusable workspace assets. It can answer questions against connected business data, while still requiring human review for important SQL and conclusions.

Setup starts with a supported datasource, least-privilege credentials, and the schemas or tables the workspace should access. People can ask questions in plain language, but teams should still learn how to review generated SQL, validate important results, and apply their business context.

Answers can include plain-language explanations, the executed SQL, result previews, and supported visualizations. Useful queries can be saved to the library and reused in dashboards or reports rather than rebuilt in every chat.

Plan availability, seat allowances, trials, and usage terms can vary by deployment and current commercial offering. Check the current plan information or contact the configured support team for the terms that apply to your workspace.