Hex

The fragmentation Hex addresses

A piece of analysis typically passes through several tools.

The data is queried somewhere that can run SQL. Then it moves to a notebook for the parts SQL is awkward at. Then the conclusion is written up somewhere else, with charts pasted in. Then somebody asks to try different inputs, and there is nothing to give them.

Four artefacts, three copies of the data and no single place that represents the work.

Hex puts the whole sequence in one project.

Cells that are not all the same kind

A project is made of cells, and the useful part is that they need not all be one type.

A SQL cell queries a connected source. A Python cell operates on the result. A configured cell produces a chart or a transformation without code being written.

Results pass between them. A SQL result is available to Python as a data frame, so the boundary that normally requires an export and a reimport is not a boundary here.

That means each part of the work can be done in whichever form suits it, rather than everything being forced into one language because that is what the tool speaks.

Publishing changes what a project is for

The capability that most distinguishes Hex is that a project can be published as an application.

The same project, with a chosen layout and input controls, becomes something colleagues use. They see the controls and the results. They do not see the cells.

The consequence is that there is one artefact rather than two. In the usual arrangement, an analysis and the application built from it are separate things that drift apart. Here the thing colleagues are using is the analysis, so it cannot be out of date relative to itself.

Collaboration

Projects live in a shared workspace rather than on individual machines.

That sounds administrative and it changes the quality of the work. Analysis that others can open is analysis that can be reviewed, questioned and picked up by somebody else. Analysis on a laptop is none of those things.

Who uses Hex

Hex is used by analytics and data science teams whose work spans SQL and Python, and by organisations that want analysis both reviewable by colleagues and usable by a wider audience without a second build.

Points to consider

Creating content requires SQL and, for much of what makes it worthwhile, Python. It is aimed at analysts and data scientists rather than at business users building their own content.

Connections and how query results are handled are worth reading in the documentation where data handling matters, since the tool sits between users and the sources it queries.

For a team wanting only dashboards over modelled tables, a business intelligence tool is a more direct fit than a workspace built around code.

Getting started

The documentation covers connecting a data source, building a project with SQL and Python cells, adding input controls and publishing the result as an application. Building a project with one SQL cell feeding one Python cell shows how results move between them.