LightGBM vs xgboost: leaf-wise growth versus a portable distributed stack
Both are C++ gradient boosting libraries for tabular data, and both ship Python and R bindings. LightGBM grows trees leaf-wise to cut training time and memory; xgboost keeps a depth-wise, regularised objective and the same training code path across Dask, Spark, Hadoop and Kubernetes. For most single-machine tabular work LightGBM is the faster default; xgboost is the safer pick when the cluster you already run is the constraint.
At a glance
| Project | lightgbm-org/LightGBM | dmlc/xgboost |
|---|---|---|
| Licence | MITPermissive: commercial use allowed | Apache-2.0Permissive: commercial use allowed |
| Maintenance | Commits in the last six monthsLast push October 2, 2026 | Commits in the last six monthsLast push October 11, 2026 |
| Language | C++ | C++ |
| GitHub stars | 18,832 | 28,850 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose LightGBM if you train gradient boosted trees on tabular data where training time or peak memory is the binding constraint, you can pin a version and read the Parameters page before writing a config, and your platform is covered by the installation guide.
Choose xgboost if you need one training code path that also runs on Dask, Spark, Hadoop or Kubernetes, you want bindings beyond Python and R (Java, Scala, C++), or you want an Apache-2.0 licence with a published paper behind the algorithm.
Two answers to the same question: how to grow a boosted tree
Both projects implement gradient boosted decision trees in C++, and both expose that core through language bindings. The difference is in the tree growth policy and in what the project optimises for. LightGBM's README describes a framework designed to be distributed and efficient, listing faster training speed, lower memory usage, support for parallel, distributed and GPU learning, and handling of large-scale data. The mechanism behind the speed claim is leaf-wise growth: the tree expands the leaf with the largest loss reduction rather than splitting every node at a level, so a tree of the same depth is reached with fewer splits. That is also the source of its main tuning trap. Leaf-wise growth on small datasets overfits unless you cap num_leaves or set min_data_in_leaf, and the Parameters page is the exhaustive list of the keys that control this. Our analysis of LightGBM says to read that page before writing a config file, because key names are exact and unforgiving.
XGBoost's README describes an optimised distributed gradient boosting library designed to be efficient, flexible and portable, implementing algorithms under the gradient boosting framework, with parallel tree boosting that runs on Kubernetes, Hadoop, SGE, Dask, Spark and PySpark. Its lineage is a 2016 KDD paper by Tianqi Chen and Carlos Guestrin, and the regularised objective in that paper is still the reference point for how the library is documented. In practice the split is less about which produces better trees on a clean tabular problem and more about the shape of the surrounding system. LightGBM optimises the inner loop; xgboost optimises the number of places that inner loop can run unchanged.
Getting each one running
LightGBM's README points new users at the installation instructions on readthedocs, and the badge list shows packages on PyPI, conda-forge, CRAN, NuGet and winget. That spread matters if your team is not all Python: the R package is a first-class binding, and there is a SWIG wrapper build in CI. The repository moved from Microsoft/LightGBM to lightgbm-org/LightGBM in March 2026, and the README states that the new location is still the official source, managed by the same maintainers including the creator of LightGBM. Our analysis of LightGBM says the practical consequence is that you should pin a version and make sure your install scripts, mirrors and internal documentation point at the new organisation rather than the old one. The latest release listed is v4.7.0 from 18 July 2026, with v4.6.0 in February 2025 and v4.5.0 in July 2024, so releases are not frequent and pinning is cheap.
XGBoost's README links to PyPI, CRAN and conda-forge packages and to a Colab notebook, and the description names bindings for Python, R, Java, Scala and C++. Our analysis of xgboost says to verify three things in your own environment before committing: that the pip wheel matches your platform, that the installed Python package version matches the XGBoost version you query at runtime, and that your evaluation metric is the one you actually care about, because the library will optimise whatever you pass it. That last point is not a defect, but it is the most common way a pipeline silently optimises the wrong thing. The release cadence is tighter here: v3.4.1 on 15 August 2026, v3.4.0 on 4 August 2026, v3.3.0 on 17 June 2026.
Distributed training: where the two designs diverge most
LightGBM's README links to a Distributed Learning guide and a GPU tutorial, and states that distributed learning experiments show linear speed-up using multiple machines in specific settings. The phrase in specific settings is doing real work: LightGBM's distributed modes have their own configuration surface, and the repository also documents FLAML for automated tuning and links Optuna, so the tuning stack is expected to sit alongside the training library rather than inside it. If your scale is one large machine with many cores, LightGBM's defaults are already aimed at that case, and the README's memory claim is the reason teams move to it from other boosters.
XGBoost's portability claim is the stronger one on paper. The README says the same code runs on Kubernetes, Hadoop, SGE, Dask, Spark and PySpark, and that it can solve problems beyond billions of examples. That is a statement about operational surface, not about accuracy per core. If your organisation already runs Spark or a Kubernetes operator, the cost of adding a second training system is usually higher than the cost of a slightly slower booster, and xgboost's pitch is that you do not have to add one. The trade is that you inherit the constraints of the distributed environment you chose. Our analysis of xgboost says it is the right adoption when you have tabular data, a Python or R workflow, and a need for one training code path that also runs on Dask, Spark or Kubernetes.
Where each one falls short
LightGBM's weaknesses are the mirror of its strengths. Leaf-wise growth is fast and memory-light, and it is also easier to overfit on small or noisy tabular sets, which puts the burden on the tuner to set num_leaves and min_data_in_leaf sensibly. Our analysis of LightGBM says not to adopt it if you need a model you can explain leaf by leaf to a non-technical reviewer; the trees are not built to be read as rules. The repository move is a second, smaller cost: teams that cannot track the change from Microsoft/LightGBM to lightgbm-org/LightGBM in March 2026 will find stale install instructions in their own tooling. That is a documentation problem, not a code problem, but it lands on whoever maintains the build.
XGBoost's weaknesses are different. It is not a first step for image, audio or long text sequence data, and it does not give you a model you can read as a set of if-then rules. Its flexibility is also a footgun: the library optimises the metric you hand it, so a pipeline that passes the wrong objective will train happily and report numbers that do not match the business question. The distributed story is broad but not free. Running on Spark or Hadoop means your debugging happens in that environment's terms, and a version mismatch between the installed Python package and the runtime XGBoost version is a failure mode our analysis of xgboost flags explicitly.
Licence and maintenance: MIT against Apache-2.0
LightGBM is MIT licensed. XGBoost is Apache-2.0. For most internal training pipelines the difference is administrative rather than legal: both permit commercial use, and the Apache-2.0 patent grant is the reason some legal teams prefer it for code that ships inside a product. If your review process has a list of approved licences, check which identifier is on it before you pick, because switching boosters later means re-validating models, not just swapping an import.
On maintenance, the facts table tells most of the story. LightGBM's last push was 17 September 2026 and xgboost's was 26 September 2026, both recent, and neither repository is archived. XGBoost's release history is denser: three releases between June and August 2026. LightGBM's most recent listed release is v4.7.0 from 18 July 2026, with a longer gap before it. Denser releases are not automatically better; they do mean more chances to pick up a fix and more versions to test against. LightGBM's lower release frequency makes pinning simpler, which suits teams that cannot re-run a model validation cycle every quarter. Both projects are C++ at the core, so neither is a pure Python dependency you can audit by reading the source in an afternoon.
Choosing for a concrete scenario
For a single-machine tabular pipeline where training time or peak memory is the constraint, LightGBM is the default. The README's efficiency and memory claims are the reason, and the leaf-wise mechanism is the reason behind the claims. Budget time for the Parameters page and for capping tree complexity, and pin a version so the March 2026 repository move does not surprise your build. For a team already running Spark, Dask or Kubernetes, xgboost is usually the cheaper addition: one training code path across those environments is worth more than a faster single-node fit, and the Apache-2.0 licence and the 2016 paper give reviewers something concrete to point at. For a Python-only team with a small dataset and no cluster, both work, and the deciding factor is likely which one your existing evaluation harness already calls.
The two are complementary more often than the framing suggests. LightGBM's README points at FLAML and Optuna for tuning, and xgboost links Optuna in its own badge list, so a team can tune one and train the other without building new infrastructure. The realistic pattern is to prototype on LightGBM for speed, then move the winning configuration to xgboost if the deployment target is a distributed environment, or the reverse if the deployment target is a single large machine. What you should not do is assume the two are drop-in replacements. Parameter names differ, defaults differ, and a config file written for one will not run on the other without translation.
Bottom line
Pick LightGBM when the bottleneck is training time or memory on one machine and you can invest in reading the Parameters page and pinning a version. Pick xgboost when the bottleneck is where the training has to run, or when an Apache-2.0 licence and a published algorithm paper matter to your review process. Before committing to either, verify your platform against the installation guide, confirm the installed package version matches the version your code queries at runtime, and check that the metric you pass is the one your business actually cares about. If your team runs both, treat them as two configurations of the same problem rather than as interchangeable imports.