mljar-supervised: AutoML for Tabular Data That Writes Down What It Did
Python package for AutoML on Tabular Data with Feature Engineering, Hyper-Parameters Tuning, Explanations and Automatic Documentation
At a glance
- What is it?
- mljar-supervised is an MIT-licensed Python AutoML package for tabular data whose distinguishing feature is a per-model Markdown report rather than a hidden pipeline. The trade-off is that its four training modes and its report generation are the product, so anyone who only wants a leaderboard of scores will pay for machinery they do not use.
- Who is it for?
- Adopt mljar-supervised when the deliverable includes an explanation of how the model was built, because the per-model Markdown report is the part you cannot easily get elsewhere. Do not adopt it when you need a fixed, hand-tuned pipeline with a known inference cost, or when you cannot accept the dependency set that LightGBM, XGBoost, CatBoost and the neural network stack bring in.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 51 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: A Pipeline You Cannot Read Afterwards
Fitting a model is the short part of a tabular project. The long part is remembering, months later, which imputation was used, which categorical encoding was applied, and why one algorithm beat another. mljar-supervised targets that gap. The README states it is designed to save time for a data scientist and that it abstracts the common way to preprocess the data, construct the machine learning models, and perform hyper-parameters tuning. The claim that matters is the next sentence: it is no black box, as you can see exactly how the ML pipeline is constructed, with a detailed Markdown report for each ML model. That is the product. Not the leaderboard, the record. The intended user is a data scientist or analyst who has to hand a result to someone else, or who has to justify a model choice to a reviewer. If you are the only person who will ever read your own notebook, the reports are overhead.
Four Modes, Four Different Budgets
The README describes four built-in modes, and they are not cosmetic presets. Explain mode is aimed at understanding data, and the documentation lists decision tree visualization, linear model coefficients, permutation importance and SHAP explanations among its outputs. Perform is described as building ML pipelines to use in production. Compete trains highly tuned models with ensembling and stacking for competitions. Optuna, available since version 0.10.0, is for when performance matters most and computation time is not limited. The README adds that you can customize the details of each mode. The practical reading: mode selection is a compute-budget decision as much as an accuracy decision. Optuna explicitly trades time for score, which means it is the wrong default for a nightly job on a large table. Choosing Compete when you wanted Perform buys you stacking you then have to serve.
Algorithms, Ensembling and What Gets Preprocessed
The algorithm list in the README is Baseline, Linear, Random Forest, Extra Trees, LightGBM, Xgboost, CatBoost, Neural Networks and Nearest Neighbors. Ensembling uses a greedy algorithm attributed to the Caruana paper, and stacking can build a level 2 ensemble, available in Compete mode or by setting the stack_models parameter. On the data side, the README says the package does feature preprocessing such as missing value imputation and converting categoricals, and that it can also handle target value preprocessing. Beyond that it lists Golden Features, feature selection, and text and time transformations as advanced feature engineering. The consequence worth naming: because target preprocessing is in scope, the transformation applied to y is part of the pipeline, and anything you do downstream with predictions has to account for it. That is a place where reading the generated report is not optional.
Automatic Documentation Is the Reason to Pick This
Every model gets a Markdown report describing how its pipeline was constructed, according to the README. This is a different kind of artifact from a metrics table. A metrics table tells you which model won. A pipeline report tells you what the winner actually is, which is the question that blocks handover and review. The README also frames explanation as a first-class output: model reports, feature importance, and SHAP explanations. If your organisation requires a written record of model construction, this is the feature to evaluate, and it is the one to test first on your own data rather than the one to take on faith. If your organisation does not require that record, most of the value proposition evaporates and you are left comparing raw scores against every other AutoML tool.
Turning a Trained Model into a Web App
The README documents a path from CSV to trained model to prediction web app, generated with Mercury. The example is three lines: construct AutoML with results_path set to "AutoML", call fit on X and y, then call automl.app(). For local use there is automl.local_app(), and for publishing there is automl.publish_app(). The README states that publish_app() creates an app URL on the first publish and then reuses the last successfully published URL by default, which is the behaviour you want in a repeatable job and the behaviour you need to know about if you expected a fresh URL each time. The generated app can include a single prediction dashboard, batch prediction from CSV files, downloadable predictions, feature importance plots, and feature context plots for single predictions. The audience named in the README is domain experts, business users and researchers who do not want to work directly with Python. That is a specific and reasonable target. It is also a deployment surface, and the README does not describe authentication or access control for the published app, so treat that as something you must establish yourself.
Where It Is the Wrong Tool
Two cases stand out. First, latency- and cost-sensitive serving. Compete mode stacks models to build a level 2 ensemble, and an ensemble of LightGBM, XGBoost, CatBoost and a neural network is not a single artifact with a predictable inference cost. If your serving budget is fixed, a hand-built single LightGBM model is the better choice and mljar-supervised is the wrong entry point. Second, tight dependency environments. The algorithm list implies a heavy install, and the README's installation section is not reproduced in full here, so the exact dependency footprint is something to check against your own constraints before you commit. There is also a softer failure mode: the package searches over preprocessing, feature engineering and hyper-parameters, and a search that runs unattended on a large table can consume a compute budget you did not intend to spend. Optuna mode is described as being for when computation time is not limited, which is a warning as much as a feature.
Compared with Plain scikit-learn Pipelines
The honest alternative is scikit-learn, which the README lists among the project's topics and which supplies the Pipeline and ColumnTransformer primitives for the same preprocessing work. The difference is who decides. With scikit-learn you write the imputation, the encoding and the model choice yourself, and you get exactly that pipeline at inference time with no search overhead and no surprise in the artifact. With mljar-supervised you declare a mode and a results path and the package searches across algorithms, preprocessing and hyper-parameters, then writes down what it found. You are trading control and predictability for search and documentation. Neither is universally better. If you already know your pipeline is LightGBM with median imputation and ordinal encoding, scikit-learn is less machinery for the same result. If you do not know, and you need to show your reasoning, the search plus the report is the point.
Maintenance, Licensing and What to Verify First
The licence is MIT, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and you should confirm it against your own policy. The project is not archived, and the release history shows v1.3.0, v1.3.1 and v1.3.2 within roughly two months, so the maintenance signal is active development rather than a frozen artifact. The README also points to commercial support and to MLJAR Studio as a hosted way to run the same AutoML, which means the open source package and a paid product sit side by side. That is worth knowing before you standardise on the package: features you read about in the README may be documented primarily in the context of the hosted product. Upgrade cost is the usual one for a search-based tool. Because results are written under results_path, an upgrade can change which pipeline wins on the same data, and any downstream artifact keyed to a specific model has to be re-validated rather than assumed stable. Before adopting, train one representative dataset in Explain mode, open the Markdown report for a single model, and confirm that the recorded preprocessing matches what your team would have written by hand.
Editorial conclusion
Adopt mljar-supervised when the deliverable includes an explanation of how the model was built, because the per-model Markdown report is the part you cannot easily get elsewhere. Do not adopt it when you need a fixed, hand-tuned pipeline with a known inference cost, or when you cannot accept the dependency set that LightGBM, XGBoost, CatBoost and the neural network stack bring in. Before committing, run one dataset through Explain mode, open the generated Markdown report for a single model, and read the preprocessing steps it records, since that report is what you are actually buying.
Community notes