Starburst connects AI analytics to governed data across existing systems

Starburst addresses a practical AI problem: business information is spread across systems, and useful answers depend on consistent definitions as much as model capability. Its platform combines access to distributed data with governed data products and AIDA, a conversational analytics assistant. For a team choosing where to add AI, the decision is whether an existing data estate needs a common query and context layer, and who will maintain that layer as the underlying systems change.

01 / ProductAIDA sits above the data products a team chooses to expose

The AIDA product overview positions Starburst as a way to ask questions across existing data systems. Galaxy is the managed cloud route; Starburst also offers a self-managed Enterprise platform. This Blueprint uses the current Galaxy documentation for its proposed workflow. Availability or configuration in another deployment should be checked separately rather than inferred from a shared product name.

The Galaxy documentation explains the mechanism more precisely than the broad promise of conversational analytics. AIDA takes a natural-language question, generates and executes SQL against the selected data product, and presents the result. It may first run exploratory queries and refine its approach. That makes dataset curation a substantive implementation task: the assistant does not automatically understand every table in the organization.

A useful data product gives a question a bounded meaning. A sales dataset might distinguish booked orders from recognized revenue, identify its currency, and explain how refunds are represented. These definitions make it possible to judge the generated query. Without them, a plausible number can answer a different question from the one the business intended.

02 / AudienceThe strongest fit is an existing estate with cross-system questions

Starburst is worth investigating when information lives in several warehouses, databases or object stores and a business question needs a governed view across them. An analytics team can create a reusable product rather than repeatedly exporting spreadsheets for each request. The return is conditional on the work being repeated often enough to justify the integration and stewardship effort.

A small application with one well-understood database may not need another query platform simply to add a chat interface. Equally, an organization with no agreed metric definitions will still need to resolve those disagreements. Natural-language access changes how people ask; it does not decide which accounting period or customer identity is authoritative.

The comparison with Snowflake is about the data platform already in use and where an additional access layer helps. Databricks is also relevant when the same project needs extensive data engineering or model development. These are architecture choices to evaluate against the actual estate, not a claim that one product wins every workload.

03 / WorkflowProposed workflow: investigate returns across orders and support data

Consider a retailer whose order records and support cases live in different systems. The proposed evaluation asks which product categories show an increase in returns, then checks whether support contacts offer a useful explanation. It begins with an analyst-approved query and a small dataset whose answer can be independently established, rather than an open-ended executive question.

1. 01

   Define the comparison

   Choose a completed reporting period, one currency and a rule for matching support cases to orders. Keep cancelled orders and partial refunds explicit so that a join cannot silently change the denominator.

2. 02

   Prepare the data product

   Expose the approved tables or views, document the business terms and assign the evaluating role only the access it needs. Include examples that demonstrate the intended calculation.

3. 03

   Ask and inspect

   Ask AIDA for return rates by category, inspect the resulting SQL and compare totals with the analyst baseline. Follow up with a request to explain the joins and exclusions.

4. 04

   Exercise a boundary

   Repeat with a role that cannot see a restricted region. Check both the returned rows and whether the narrative makes unsupported inferences about information it cannot access.

5. 05

   Assess operating cost

   Record the compute and AIDA usage alongside accepted answers. Include exploratory queries and follow-up questions, because the apparent single interaction may involve several operations.

For an external assistant, Galaxy MCP supplies a separate integration route with read-only SQL tools. Its documented prerequisites require Mission Critical, Enterprise or a free-trial account. OAuth is recommended for production, and public API tokens are not supported for this authentication path. Read-only queries still expose information, so the client identity and accessible data products remain part of the evaluation.

The pilot succeeds when another analyst can reproduce the answer and understand why the assistant selected those records. A chart that looks convincing is insufficient. In this example, an explanation connecting support contacts with returns is a hypothesis unless the data supports that relationship; a correlated increase does not establish its cause.

04 / PricingCompute credits and assistant tokens need separate budget lines

The usage and billing guide separates the resources being measured from the price of a credit. Tier features and support affect the credit price; workload activity determines consumption. AIDA token usage should be inspected as its own charge rather than treated as an unlimited inclusion. The public starting price therefore cannot be multiplied by the number of people asking questions to produce a reliable monthly budget.

The pricing page describes a 30-day trial with US$500 of Galaxy compute resources and Enterprise-tier access, followed by a downgrade to Free. Confirm the assistant entitlement and any token allowance before planning the trial around them. A trial is useful for estimating a repeatable workload, but its credits are not a perpetual operating subsidy.

For a realistic estimate, separate routine queries, exploratory sessions, ingestion and any external model client costs. Retain the same dataset and question set when comparing configurations. Otherwise a cheaper run might simply have queried less information or failed to deliver the answer required by the business.

05 / DistinctionsA shared data definition can serve analysts and agents

The interesting design choice is the placement of the AI interface above curated enterprise context. A data product can establish the scope before a question is translated into SQL. This gives the team a concrete place to fix ambiguity: improve a definition, remove an unsuitable field, or supply an example rather than continually rewriting prompts in individual conversations.

Federated access may also reduce the need for a separate copy solely for one analytics use case. It does not remove all movement, source-system cost or network dependencies. The meaningful comparison is the complete query path, including what happens when a source is slow or its schema changes, rather than a generic claim that fewer platforms always means lower cost.

The MCP interface makes that governed query capability available to a broader assistant workflow. Its documented read-only boundary is useful for an initial analysis pilot. An assistant that can retrieve data still needs separate authorization before it sends a report, modifies a system or acts on a recommendation.

06 / QuestionsInspect model control and the limits of conversational output

The AIDA guide says the service uses Starburst-selected models through a Starburst-managed AWS Bedrock deployment; users cannot configure an alternative LLM for AIDA. It also documents a 500-row truncation before chart generation. Teams should establish whether these conditions fit their evaluation, especially when comparing a visualization with a complete result export.

The larger unresolved question is accuracy on the company’s own terminology. Build a test set containing ambiguous time periods, missing values and join traps. Have data owners score whether each answer uses the intended definition. Track unanswered questions as well as incorrect answers: declining to guess can be better than supplying a confident explanation from incomplete evidence.

07 / DecisionChoose the next step from the state of your data estate