TFX: A Configuration Framework for TensorFlow Pipelines, With a Dependency Matrix You Have to Read
TFX is an end-to-end platform for deploying production ML pipelines
At a glance
- What is it?
- TFX packages ML pipeline components that write to an ML Metadata backend and run under Airflow or Kubeflow Pipelines. The interesting part is not the component list but the version compatibility table, which pins every major dependency by hand.
- Who is it for?
- Adopt TFX if you already run TensorFlow models in production and want pipeline components whose artifacts are tracked in ML Metadata so runs can be resumed or warm-started. Do not adopt it if you only need a single training script, or if you are not prepared to hold apache-beam, ml-metadata, tensorflow-transform and the other pinned packages at the versions listed for your chosen tfx release.
- 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 11 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 TFX solves is artifact tracking between pipeline stages, not model training
Training a model is a script. Keeping track of which dataset, which transform graph and which evaluation produced a given deployed model is the harder problem, and it is the one TFX is built around. The README describes TFX as a configuration framework for expressing ML pipelines made of TFX components, and states that those components interact with an ML Metadata backend that records component runs, input and output artifacts, and runtime configuration. That backend is what makes experiment tracking and warmstarting or resuming models from previous runs possible, according to the README. The audience is therefore teams that already have a TensorFlow model and now need repeatable pipeline execution with a record of what happened. If your work stops at a training script, the component model adds a layer you will not use.
Components plus an orchestrator plus ML Metadata: the three moving parts
The architecture has three layers. The first is the set of TFX components, which the README describes as configurable and extendable. The second is the orchestrator: TFX pipelines can be run under Apache Airflow or Kubeflow Pipelines, and the README says the integrations with those systems can also be extended. The third is ML Metadata, a separate Google project, which stores the run records and artifacts. Data flows from one component to the next as artifacts registered in that metadata store, not as files passed by convention between scripts. That design is what allows a pipeline to resume or warmstart from a previous run. It also means the metadata store is a dependency you have to operate; the README does not describe a mode where TFX runs without it.
Installing TFX means picking a row in the compatibility table first
The README's compatible-versions table is the practical starting point. For tfx 1.21.0 it lists Python >=3.10,<3.13, apache-beam[gcp] 2.73.0, ml-metadata 1.21.0, pyarrow 18.1.0, tensorflow 2.21, tensorflow-data-validation 1.21.0, tensorflow-metadata 1.21.0, tensorflow-model-analysis 0.52.0, tensorflow-serving-api 2.19.1, tensorflow-transform 1.21.0 and tfx-bsl 1.21.0. The GitHub master row is nearly identical except that tensorflow is listed as nightly (2.x) and the Python range is >=3.10,<3.13. Older rows show how much moves between releases: tfx 1.17.2 pairs with Python >=3.9,<3.11, apache-beam 2.59.0, pyarrow 10.0.1 and tensorflow 2.17. The package is on PyPI, so the install is a pip install of tfx, but the table is a statement that TFX is tested against those exact versions and that other combinations are untested. The README also points to a Chicago Taxi Example under tfx/examples/chicago_taxi_pipeline for a working pipeline to read.
The compatibility matrix is the maintenance cost, and it is not small
Look at the table as a maintenance schedule rather than a footnote. A single TFX release pins eleven packages, and several of them (tensorflow-transform, tensorflow-data-validation, tensorflow-model-analysis, tfx-bsl, ml-metadata) are versioned in lockstep with TFX itself. Moving from 1.17.2 to 1.21.0 changes the Python floor from 3.9 to 3.10, the Python ceiling from 3.11 to 3.13, apache-beam from 2.59.0 to 2.73.0, pyarrow from 10.0.1 to 18.1.0 and tensorflow from 2.17 to 2.21. Any of those jumps can collide with a library elsewhere in your environment. The README is explicit that the table is determined by the project's testing framework and that untested combinations may still work, which is a warning, not a guarantee. Budget for a dependency audit each time you take a TFX upgrade, not just a version bump in a requirements file.
Where TFX is the wrong tool
TFX assumes TensorFlow. The README describes it as a Google-production-scale machine learning platform based on TensorFlow, and the pinned dependency list is entirely TensorFlow-adjacent packages. If your models are trained in PyTorch or scikit-learn, the component set does not meet you halfway. The second constraint is operational: ML Metadata is a separate backend, and the README does not present a lightweight local mode that removes it. A team that wants a notebook-to-endpoint path will find the component-and-orchestrator structure heavier than the problem requires. Third, the two supported orchestrators are Airflow and Kubeflow Pipelines. If your infrastructure standardises on something else, you are relying on the extensibility the README mentions rather than on a supported path, and you should treat that as work you own.
How TFX differs from orchestrator-native pipelines
A plain Airflow DAG is a set of tasks with dependencies and a scheduler, and it will happily run Python that trains a model. What it does not give you by default is a typed record of the artifacts each task produced and consumed. TFX puts that record in ML Metadata, and the README ties specific capabilities to it: experiment tracking, and warmstarting or resuming models from previous runs. That is the real difference in approach. The trade is that you now maintain a metadata service and a component version matrix alongside the orchestrator you already run. If your pipelines are short-lived and you can reconstruct state from object storage paths, an orchestrator-native DAG is less machinery for the same result. If you need to answer which data and which transform produced the model currently serving traffic, the metadata layer is the reason to choose TFX.
Release cadence, licensing and what to check before you commit
Recent releases listed for the repository are v1.21.0 (June 2026), v1.17.3 (April 2026) and v1.17.2 (March 2026), so the project is active and the 1.17 line received patch releases after 1.21.0 shipped. The repository is not archived. TFX is licensed under Apache-2.0, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and you should have your own counsel review obligations around notices and any bundled third-party components. The README also points to a quarterly-updated ROADMAP.md and a RELEASE.md for detailed changes, plus an RFC process for community contributions; those files are where you would confirm whether a behaviour you depend on is scheduled to change. The homepage is tensorflow.github.io/tfx and the user guide lives in docs/guide/index.md in the repository. Before adopting, read the row of the compatibility table for the exact tfx version you intend to install, and confirm your Python interpreter and your ML Metadata deployment match it.
Editorial conclusion
Adopt TFX if you already run TensorFlow models in production and want pipeline components whose artifacts are tracked in ML Metadata so runs can be resumed or warm-started. Do not adopt it if you only need a single training script, or if you are not prepared to hold apache-beam, ml-metadata, tensorflow-transform and the other pinned packages at the versions listed for your chosen tfx release. Before committing, verify three things: that your Python version falls inside the range for your target release (1.21.0 requires >=3.10,<3.13), that your orchestration choice (Airflow or Kubeflow Pipelines) is one of the two the README names, and that your ML Metadata backend can be deployed separately from the pipeline workers, since component runs are recorded there.
Community notes