yandex-research/rtdl: A Paper Index Where the Python Package Is the Deprecated Part
Research on Tabular Deep Learning: Papers & Packages
At a glance
- What is it?
- RTDL is a Yandex Research hub that links papers and per-paper code repositories on deep learning for tabular data. The umbrella rtdl package is deprecated, and the README says so explicitly, which changes how a new user should approach the repository.
- Who is it for?
- Adopt this repository as a reading list and a pointer to per-paper code, not as a library. If you already depend on rtdl==0.0.13 from PyPI, the README says the same MLP, ResNet and FT-Transformer models live in rtdl_revisiting_models with a slightly different API, so check that API before rewriting call sites.
- Can I use it commercially?
- Yes. Apache-2.0 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 152 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
What the repository actually is, and who it is for
RTDL stands for Research on Tabular Deep Learning. The repository is a curated index: a list of papers with links to arXiv and, for most entries, a separate GitHub repository holding the code. It is not a monorepo of models. The papers span 2019 to 2026, from Neural Oblivious Decision Ensembles through TabR, TabDDPM, TabM and TabReD to the 2026 optimizer benchmarking work. The README describes it as "a collection of papers and packages on deep learning for tabular data", and that word collection is doing real work: the value is in the pointers, not in a single installable artifact.
The audience is narrow. This is for researchers and engineers who already work with gradient-boosted trees on tabular problems and want to know what the deep learning literature claims, or who need a specific model such as FT-Transformer or TabR and want the authors' own implementation rather than a reimplementation. Someone who wants a batteries-included tabular library with a stable API will be frustrated here, because the repository deliberately does not offer that. Each paper's code lives in its own repository with its own structure, dependencies and maintenance status.
The deprecation notice is the most important thing in the README
The README opens with a note that the project list is up to date but the rtdl Python package is deprecated. It then distinguishes carefully: the repository is not deprecated, only the package. That distinction matters because the naming invites confusion. A reader who finds the repository, sees the name rtdl, and runs pip install rtdl is installing the deprecated artifact.
The note gives two migration paths. If you used rtdl==0.0.13 from PyPI, the same three models (MLP, ResNet, FT-Transformer) are available in rtdl_revisiting_models, with a slightly different API. If you used the unfinished code from the main branch, the README states it is highly recommended to switch to the new packages, and gives a reason: the unfinished implementation of embeddings for continuous features contained many unresolved issues. The replacement, rtdl_num_embeddings, is described as more efficient and correct. That is an unusually direct admission from a research group, and it is the kind of detail that should decide whether you pin an old commit or migrate.
How the pieces fit together: index, papers, per-paper packages
The architecture here is organizational rather than technical. This repository holds the README and, based on the release history, serves as the announcement channel: the three most recent releases are titled after paper batches, such as "tabm-and-tabred" and "optimizers-uncertainty-tfmfinetuning". The README tells readers to follow announcements via Watch, then Custom, then Releases. So the data flow is: a new paper appears, a release is cut here, and the actual code lands in a sibling repository.
Two entries break the pattern by also shipping a package. The 2022 numerical embeddings paper points to rtdl-num-embeddings and to a package README inside it for rtdl_num_embeddings. The 2021 revisiting-models paper points to rtdl-revisiting-models and to rtdl_revisiting_models. These are the two packages the deprecation note directs you toward. Everything else, including TabM, TabR, TabDDPM and the TabReD benchmark, is code attached to a paper rather than a maintained library. Treating those as dependencies means accepting whatever interface the paper authors needed for their experiments.
Getting it running: what the README does and does not give you
There is no install command for this repository in the supplied material, because there is nothing to install. The only pip invocation quoted in the README is the one it warns about: pip install rtdl. The migration targets are named as packages, rtdl_revisiting_models and rtdl_num_embeddings, but the README does not print their install lines; it links to package READMEs inside their respective repositories, which is where the actual commands live. That is a deliberate delegation, and it means you cannot get from this page to a working environment without two more clicks.
The practical workflow the README implies is: pick a paper from the list, follow its Code link, and read that repository's own instructions. For TabM specifically, the entry includes a Usage link pointing at a section titled "Using TabM in practice", which suggests the TabM repository is the one place where practical deployment guidance is explicitly signposted. If you are evaluating this ecosystem, start there rather than here. Nothing in the supplied material describes a config file, environment variable or CLI for the index repository itself.
Where this approach breaks down
The obvious limitation is that an index cannot enforce consistency. Each linked repository has its own dependencies, its own PyTorch version expectations and its own commit history, and the README gives no compatibility matrix. A model from 2021 and a benchmark from 2024 may not coexist in one environment without work, and nothing here tells you whether they do.
The second limitation is the deprecation itself. Anyone who adopted rtdl before the note was added is now on a migration path with two documented destinations and no stated timeline. The README does not say when the package was deprecated, whether the PyPI release will be yanked, or how long the old API will remain installable. It also does not quantify the "unresolved issues" in the main-branch embedding code, so you cannot judge from this page alone whether your particular use of continuous-feature embeddings was affected. If your pipeline depends on that code, the only safe reading is the README's own: switch.
Third, this is the wrong tool if you want a stable, versioned, documented tabular library with support commitments. Nothing in the material suggests API stability guarantees for any of the linked packages. It is a research index, and research code ages.
The alternative, and the actual difference
The realistic alternative for most tabular work is gradient-boosted decision trees, and the RTDL papers themselves engage with that comparison: the 2021 paper is titled Revisiting Deep Learning Models for Tabular Data, and TabReD is described as analyzing pitfalls in tabular deep learning benchmarks. The difference in approach is not just model family. A boosted-tree workflow gives you a library with a stable API, predictable training times and no GPU requirement. The RTDL path gives you the authors' research implementations, which is what you want if you are reproducing a result or testing a specific architectural idea such as parameter-efficient ensembling in TabM or nearest-neighbor retrieval in TabR.
The honest framing is that these are different jobs. If your goal is a working model on a business table by Friday, the linked research repositories are the long way around. If your goal is to know whether a deep model beats your tree baseline on your data, the papers and their code are the point, and this index saves you from searching for them individually.
Licence, maintenance and what to verify before you commit
This repository is Apache-2.0. That covers the index. It does not automatically tell you the licence of each linked paper repository, and the supplied material does not state them. If you intend to ship code derived from TabR, TabDDPM or any other linked project, check that repository's own licence file first. This is not legal advice; it is a statement about what the material here does and does not establish.
On maintenance cost: the repository itself is alive, with a push in April 2026 and releases cut per paper batch, so the index is being kept current. The per-paper code is a different question. Research repositories typically receive fixes while the paper is active and then slow down, and the deprecation of the rtdl package is a concrete example of that lifecycle playing out. Upgrading means tracking two things at once: the package you actually import, and the paper repository whose code you copied. Budget for reading each linked repository's README rather than assuming the API you learned from one applies to the next.
Editorial conclusion
Adopt this repository as a reading list and a pointer to per-paper code, not as a library. If you already depend on rtdl==0.0.13 from PyPI, the README says the same MLP, ResNet and FT-Transformer models live in rtdl_revisiting_models with a slightly different API, so check that API before rewriting call sites. If you pulled the unfinished main branch, the README recommends switching to the new packages because the continuous-feature embedding implementation had unresolved issues. Verify the licence of the individual paper repository you clone, because the Apache-2.0 notice here covers this index, not necessarily the code behind each link.
Community notes