Rath: an AGPL-licensed EDA workbench that picks the charts for you

The problem Rath targets: EDA is slower than the analysis it feeds

Exploratory data analysis is mostly mechanical. You load a table, look at column types and missingness, try a histogram, notice a skew, try a log transform, then start cross-tabbing pairs to see which ones move together. None of that is hard, and all of it is repetitive enough that people skip steps and go straight to the model.

Rath's stated aim is to automate that loop. The README describes it as an augmented analytic engine that discovers patterns, insights and causals, and presents them with auto-generated multi-dimensional visualizations. The audience is the analyst or data scientist who already knows what a good chart looks like and does not want to spend the first hour of every dataset building one.

The framing the project uses is worth quoting because it sets the design constraint: the README says Rath generates or recommends visualizations based on minimizing the visual perception error of information in visualizations. That is a specific claim about how the recommendation is scored, not a generic claim about being smart. It is also the part of the project that is hardest to evaluate from the outside, because the README does not link to the scoring method.

There is a second audience implied by the README's comparison to Tableau. Rath ships a Tableau-like drag-and-drop exploration UI, and the README notes that manual exploration is an independent embedding module that can be used on its own. So the project is really two products in one repository: an automated engine, and a charting component you can drop into your own app.

AutoVis, Data Painter and the causal view: what the engine actually does

The pipeline visible in the README runs in a fixed order. You connect a data source (online databases, or CSV and JSON files). Rath profiles it: the README's walkthrough section shows a data profiling step that produces statistics from the source. Then data preparation, which the README describes as supporting predictive transformation operations and automatically generating suggestions for transformations and cleaning. Then exploration, which is where AutoPilot and AutoVis sit.

AutoVis is described as generating the best visualization for the data you have selected, so that you focus on variables rather than on how to build a chart. The input is a selection of columns; the output is a chart specification. Data Painter works in the opposite direction: instead of choosing variables and getting a chart, you color data points directly and the tool derives the analytical features from that interaction. The README links a separate video for Data Painter, which suggests the interaction model is easier to show than to describe.

Causal Analysis is the most ambitious item on the feature list. The README says it identifies and examines causal relationships between variables, and lists three uses: exploring data, building better prediction models, and making business decisions. The repository topics include causal-discovery and causal-inference, so this is a first-class part of the codebase rather than a demo. What the README does not do is name the algorithm, state its assumptions, or describe what happens when those assumptions fail. For a feature whose output is a causal claim, that omission matters more than it would for a histogram.

The natural language interface integrates with GPT to generate answers and visualizations from questions about your data. That is the one feature in the list that necessarily sends data or a description of it to a third party, and the README does not say which.

Getting it running means reading past the README

This is the weakest part of the supplied material. The README has a Get started section, and it contains three links: a sandbox demo at rath.kanaries.net, the documentation at docs.kanaries.net, and a video about Data Painter. It does not contain an install command, a clone command, a package manager invocation, an environment variable name, or a configuration key.

So there is nothing here to quote as a working setup sequence, and I will not invent one. What can be said from the repository metadata is that the project is primarily TypeScript, the default branch is master, and the homepage points at the hosted sandbox rather than at a self-hosting guide. Anyone evaluating Rath for internal deployment should treat the docs site as the actual entry point and expect to spend time there before they can answer basic questions about build steps and runtime configuration.

The one concrete integration detail the README does give is on the Python side, and it is for a different product: the tip block mentions runcell, an AI code agent for Jupyter, installed with pip install runcell. That is not Rath. It is a sibling project from the same organisation, offered as the place to go if you want more AI features. Reading the README carefully, the only install command present belongs to something else, which is an unusual thing to find in a project's primary documentation.

The GPT-backed question answering is the feature most likely to require configuration before it works, since it depends on an external model provider. The README does not name the provider, the environment variable, or the endpoint. Verify that before you plan around the feature.

Where Rath is the wrong tool

The release history is the first constraint. The most recent release listed is 2.1.0, dated 25 August 2023. Before that, 2.0.0 in April 2023 and v2.0-beta in July 2022. The last push to the default branch is dated 14 August 2026, so the repository is not archived and work has continued, but it has continued without a tagged release for roughly three years. If your organisation requires a versioned artifact with a changelog, you are choosing between an old tag and an unreleased master branch. Neither is comfortable.

The licence is the second constraint. Rath is AGPL-3.0. The AGPL's network clause is the part that catches people: if you modify Rath and let users interact with it over a network, the licence's obligations extend to the modified source. Embedding the manual exploration module into a proprietary product is a different question from running Rath internally, and the README's note that the module can be used independently does not answer it. I am not giving legal advice here; the point is that the licence choice is load-bearing for how you deploy this, and it should be a decision made early rather than discovered late.

The third constraint is the causal feature. A tool that surfaces causal relationships between variables is useful when the analyst understands the identification assumptions behind the result, and misleading when they do not. The README markets causal analysis as a way to make business decisions without stating any assumptions, which is the failure mode to watch for: a plausible-looking causal graph treated as an established fact by someone who did not ask how it was derived.

Finally, the automation itself is a limitation. AutoPilot generates insights in one click. Generated insights are a starting point for a human, and the README does not describe how the engine ranks or filters what it surfaces. If the output volume is high, the time saved on chart construction can be spent on triaging suggestions instead.

ydata-profiling and Tableau solve adjacent problems differently

The closest comparison in kind is ydata-profiling (formerly pandas-profiling). It is a Python library that takes a DataFrame and emits a profiling report: distributions, missing values, correlations, warnings about skewed or constant columns. It is a report generator, not an interactive application, and it stops at description. Rath goes further in two directions that matter: it produces visualizations rather than static tables of statistics, and it attempts causal discovery rather than correlation reporting. The trade is that ydata-profiling is a function call inside a notebook you already control, while Rath is an application you have to run and, if you self-host it, maintain.

Against Tableau, the README positions Rath as an open-source alternative, and the comparison is fair on the manual exploration side, where Rath offers a drag-and-drop UI in the same idiom. The difference in approach is where the intelligence sits. Tableau's model is that the analyst specifies the view and the tool renders it well. Rath's model is that the tool proposes the view and the analyst reacts. That is a real philosophical split, and it changes what you do when the suggestion is wrong: with Tableau you fix your own specification, with Rath you need to understand why the engine chose what it chose, which brings you back to the undocumented scoring method.

The other practical difference is deployment. Tableau is a commercial product with a support contract and a release schedule. Rath is AGPL-3.0 source with a three-year gap since the last tag. For a team that needs someone to call when the dashboard breaks, that gap is the whole argument.

Maintenance cost and the AGPL question

Two costs attach to Rath, and they are separate.

The first is the upgrade cost. With the latest tag at 2.1.0 from August 2023 and active commits on master through 2026, self-hosting means either pinning to a release that predates years of work or tracking a branch with no release notes to read. Neither is a maintenance plan; both are a decision about which kind of drift you prefer. The README's Get started section points at a hosted sandbox, which is the low-friction path, but it is a demo of parts of the features by the README's own description, not a deployment target for your data.

The second is the licence. AGPL-3.0 is a copyleft licence with a network-use provision. Running Rath internally and letting employees use it is one situation. Modifying it and exposing the modified version to users over a network is another, and the obligations there are the reason some organisations maintain a blanket ban on AGPL dependencies. The README does not offer a commercial licence or an exception, so if AGPL is incompatible with your distribution model, the answer is no, and it is no regardless of how good the AutoVis engine is. Whether your specific use triggers the clause is a question for your legal team, not for this article.

Who should adopt Rath, and what to check first

Rath fits teams that want a self-hosted exploration surface and are comfortable with the AGPL. The AutoVis engine and the Data Painter interaction are the reasons to pick it over a static profiling report, and the causal analysis view is the reason to pick it over a plain charting library, provided you have someone who will interrogate the causal output rather than paste it into a slide.

It does not fit teams that need a supported product with a release cadence, teams whose distribution model is incompatible with AGPL-3.0, or teams that want a library to import into an existing notebook workflow rather than an application to run. For the last group, ydata-profiling is the more direct answer.

The documentation gap is the thing to resolve before anything else. The README's Get started section is three links and no commands, so the first task is reading docs.kanaries.net for build and configuration steps and confirming they cover the version you intend to run. Then check the GPT integration: find out which provider it calls, what leaves your environment, and which environment variable carries the credential, because that determines whether the natural language feature is usable on your data at all. Then decide between the 2.1.0 tag and master, and write down why. If those three answers are not available in the documentation, that absence is itself the finding.

Editorial conclusion

Adopt Rath if you want a self-hosted, AGPL-licensed EDA surface where chart selection and transformation suggestions are generated rather than hand-built, and if you are comfortable reading the docs at docs.kanaries.net and the repository layout to work out deployment, because the README does not spell it out. Do not adopt it if you need a supported commercial product with a stated release cadence, or if AGPL obligations across your whole application are a problem. Before committing, verify three things: the exact Node and package-manager versions the master branch expects, how the optional GPT-backed natural language feature obtains credentials and where those requests are sent, and whether the 2.1.0 release from August 2023 is the build you actually want given that the default branch has moved on since.

Official sources

1. Kanaries/Rath on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases