Hex turns SQL and Python analysis into shared data apps

Hex is a collaborative analytics workspace where teams query data, develop analysis in SQL and Python, and publish interactive data apps. Its AI features help both analysts writing code and colleagues asking questions about curated data. The appeal is continuity: an investigation can become a reusable tool without being rebuilt as a separate dashboard application.

01 / ProductHex connects analysis, AI assistance and published data apps

Hex's current product¹ brings together agent-assisted notebooks, conversational analysis and data apps. It also includes Context Studio for managing the business context used by agents. This matters because a useful analytics answer needs more than a connection to a database: it needs to know which tables are trustworthy, which metric definition applies and how the organisation describes its business.

The core project environment³ combines SQL, Python or R, visual cells and explanatory text. An analyst can query a warehouse, transform the result, build a chart and document assumptions in one project. A separate app view presents selected results and inputs to people who do not need to work through the underlying code.

There are several AI experiences rather than one universal chat box. The AI overview⁵ distinguishes Notebook Agent for technical analysis, Threads for conversational questions over curated data, and Chat with App for working with a published app. The documentation explicitly expects Notebook Agent users to be able to audit its suggested code. Generative Apps is described as beta, which should remain part of any evaluation of that newer interface.

This is a Sequenced desk assessment based on public documentation. We have not run Hex against a private warehouse or measured analyst productivity. The following example explains how to assess the product with an actual business question and independently checked results.

02 / AudienceHex fits teams that repeatedly turn questions into shared tools

The clearest audience is a data team whose work spans exploratory analysis and recurring reporting. A product analyst may begin by investigating a conversion change, then publish a controlled view that product managers can revisit. An operations analyst may combine SQL data with a Python model and expose a few scenario inputs to colleagues.

That flexibility is valuable when a fixed dashboard cannot answer the whole question. A notebook can show intermediate calculations, compare definitions and investigate exceptions. The published app can then provide a simpler experience once the reasoning is settled. The two audiences share an analytical foundation while seeing different levels of detail.

Hex is less likely to solve a team's main problem if the underlying data remains fragmented, inconsistent or inaccessible. Databricks operates further into the data-platform layer, including data engineering and governed processing. Hex can sit above such a foundation; it should not be mistaken for a shortcut around building reliable source tables.

For organisations focused primarily on broad business-user search and repeatable BI experiences, ThoughtSpot offers another approach to investigate. A useful comparison asks how much custom analytical code your team needs to author and maintain, how people explore answers, and where reusable business definitions live. The right fit depends on the work between the first question and the final decision.

03 / WorkflowA trial-to-paid analysis demonstrates the notebook-to-app workflow

Suppose a software company wants to understand whether its onboarding change improved trial conversion. This is an illustrative analysis, not a claim about measured Hex results. The business wants to compare cohorts, inspect segments and return to the analysis after more trials mature.

Begin by defining the question in plain language. A trial belongs to its start-date cohort. Conversion means a qualifying paid subscription within a fixed observation window. Internal accounts and duplicate trials are excluded according to an agreed rule. Trials that have not yet completed that window should be identified separately, otherwise a recent cohort can appear weaker simply because it has had less time to convert.

Connect an appropriately scoped data source. Hex's connection documentation⁶ distinguishes reusable workspace connections from project-specific connections and describes different levels of integration support. Its schema filtering helps users and agents find relevant objects, but does not replace database permissions. For this pilot, expose the approved trial and subscription tables rather than an entire operational database.

Ask Notebook Agent to draft a query, then inspect the join before evaluating the chart. One trial can have several billing events; joining raw events directly to trials may multiply records. Build one qualifying conversion record per trial first, then calculate cohort totals. Check that the denominator equals the independently counted eligible trials and that conversions never exceed that denominator.

Use Python where it adds analytical value, such as comparing uncertainty across small segments or checking the sensitivity of results to a different observation window. Keep those choices visible in the notebook. A chart showing a larger percentage is not enough to establish that onboarding caused the change; traffic mix, seasonality and other product changes may differ between cohorts.

Publish the decision surface, with the definitions attached

Hex's App builder⁴ lets authors arrange selected cells into rows and tabs and choose whether to show code, outputs or both. For this example, publish the cohort chart, sample sizes, maturity status and filters for acquisition channel and plan. Put the conversion definition beside the chart so a reader does not need to find it in an analyst's private notes.

Give the app a clear empty state. If a filter produces too few eligible trials, show the count and explain the limitation instead of displaying a dramatic percentage without context. Add a visible data-through date. This turns the app into a decision aid whose limitations remain apparent when someone opens it without the analyst present.

Scheduled runs⁷ execute the published app version rather than draft edits. Configure the intended saved view and refresh behaviour, then verify the next published result against the expected input values. A schedule that successfully runs the wrong cohort filter can still deliver a misleading report, so execution success and analytical correctness need separate checks.

A useful pilot concludes with a colleague answering a real follow-up question through the app. Observe whether they understand the metric, choose sensible filters and interpret an immature cohort correctly. That is stronger evidence of value than counting how many cells the agent generated.

04 / PricingHex pricing separates author seats, credits and compute

The public pricing page² lists individual and team plans. Paid seats receive monthly credit grants for AI and other credit-consuming features, with additional credits available to purchase. Larger compute profiles are a separate consideration. The table is a current list-price snapshot, not a quote for a particular organisation.

An illustrative team with six paid Editors on Team would have $450 per month in Editor-seat charges at the listed rate. That is not the total analytics cost. Warehouse queries, purchased credits, advanced compute and any contractual add-ons can change the budget. Define how many people author analysis and how many mainly consume it before multiplying a headline seat price by the entire company.

The page also lists larger compute profiles, including Large at $0.32 per hour, billed per minute. For a proposed workload using 100 hours of that additional compute, the arithmetic is $32. Whether such a profile is needed depends on what executes inside Hex and what remains in the warehouse. Pulling an unnecessarily large raw table into Python can increase memory needs without improving the answer.

A practical commercial evaluation records active authors, published apps used, AI consumption and warehouse workload together. Cost per useful recurring analysis may be a better measure than cost per notebook. An abandoned project that continues refreshing can consume resources while contributing no decisions.

05 / DistinctionsThe connection between reasoning and presentation is the distinction

Hex's product design is especially relevant when analysis cannot be specified perfectly in advance. The analyst can explore alternative definitions, inspect underlying records and leave an explanation beside the code. Once the work is ready, selected outputs become an app for a wider audience. This reduces the conceptual distance between how an answer was produced and how colleagues consume it.

AI assistance can make that exploration easier, but its most useful role is often to propose a first query or help modify an existing analysis. In the trial example, the difficult part is deciding which trials are comparable and what counts as conversion. Writing the aggregation is only one step. The analyst's business understanding remains visible in the data selection and interpretation.

Context curation becomes more valuable as conversational access expands. If two tables contain similarly named revenue fields, endorsing the intended source and documenting its meaning can prevent recurring confusion. Treat repeated wrong answers as evidence of a missing definition or ambiguous data model, not merely a reason to write a longer prompt each time.

For founders and data leaders, this suggests a rollout sequence: establish one trusted analysis, publish a usable app, then support a broader range of questions over the same well-described data. Expanding access after the definitions are understood gives the team a better foundation for self-service.

06 / QuestionsFreshness, permissions and AI data use need precise checks

A report has several kinds of freshness: the source tables may be current, the last query may be old, and the published app may still show an earlier result. Displaying only the time a notebook was edited does not communicate all three. Establish which timestamp matters to the reader and expose it near the result.

Scheduling also has practical limits. Hex documents a maximum scheduled frequency of hourly and notes that runs may be delayed. Files written during scheduled or app sessions are not persistent across runs; durable outputs should go to external storage. Those details matter if someone proposes using a report project as a real-time operational process or an informal data pipeline.

Hex's AI privacy policy⁸ distinguishes third-party model-provider practices from Hex's own use of AI-session data. Providers do not train on customer data, while Hex's improvement use depends on the applicable plan and can be opted out of. Project code, output content and database metadata can provide model context. Review these actual settings and scopes rather than assuming that a no-training statement means no data is sent for inference.

07 / DecisionChoose Hex when analysis needs to become a reusable experience

Hex deserves a close look when analysts need code-level flexibility and colleagues need a clear way to use the results. The strongest pilot is a business question that currently requires repeated analyst intervention. Build the analysis, validate the numbers and publish an app that handles the common follow-ups.

Judge the outcome by whether colleagues can reach a sound decision with less back-and-forth while preserving access to the reasoning. That combines Hex's notebook heritage, its app layer and its current AI direction in a single practical test.