TensorFlow Privacy: DP-SGD Optimizers and the Cost of Per-Example Clipping
Library for training machine learning models with privacy for training data
At a glance
- What is it?
- TensorFlow Privacy wraps standard TF optimizers in differentially private counterparts and ships an accountant for computing the epsilon they buy you. The library is split across two PyPI packages as of 0.9.0, and the fast path only covers Dense and Embedding layers.
- Who is it for?
- Adopt TensorFlow Privacy if you already train in TensorFlow, your model is built from Dense and Embedding layers, and you need an epsilon number you can put in front of a reviewer. Do not adopt it if you are on PyTorch, if your architecture depends on custom layers with per-layer state, or if your privacy requirement is really about not collecting the data in the first place.
- 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 20 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 DP-SGD training actually asks of your code
The problem this library addresses is narrow and specific. A model trained on user records can memorize individual records, and a gradient step computed over a batch carries information about every example in that batch. TensorFlow Privacy provides TensorFlow optimizer implementations that train models under differential privacy, plus analysis tools for computing the privacy guarantees those training runs provide. The audience is a machine learning engineer who already has a training loop in TensorFlow and now has to attach a formal privacy claim to the resulting model. That is a different job from anonymizing a dataset before training, and it is a different job from measuring whether a trained model leaks. The library does the first kind of work: it changes the optimizer so that the training procedure itself satisfies a stated guarantee.
Per-example clipping, noise, and the microbatch trade-off
The mechanism is the standard DP-SGD construction. Instead of averaging gradients over a batch, the optimizer clips each example's gradient to a fixed norm and adds calibrated noise before applying the update. The clipping bound and the noise multiplier are the two parameters that determine the privacy cost, and the accountant converts a training configuration (batch size, number of steps, noise multiplier, sampling rate) into an epsilon at a chosen delta. The README points to a walkthrough in tutorials/walkthrough/README.md that covers wrapping existing optimizers such as SGD and Adam into their differentially private counterparts, tuning the introduced parameters, and measuring the guarantee with the included analysis tools. The interesting engineering detail is what happens to memory. Naive per-example clipping materializes one gradient per example, which is why the usual workaround is to split a batch into microbatches and clip per microbatch. The README states that a newer implementation for DP Keras models consisting only of Dense and Embedding layers uses fast gradient calculation results from arxiv.org/abs/1510.01799 to clip the gradient with respect to each example, and that this removes the need to tune the number of microbatches. That is the real selling point of the library's current direction, and it comes with a hard architectural precondition stated in the same sentence.
Installing it and the 0.9.0 package split
Installation is a single pip command for library use: `pip install tensorflow-privacy`. TensorFlow is a prerequisite and the README gives a floor of version 1.14, with a separate requirement that TensorFlow 2.4 or later is needed for the Keras-based estimators to work with tf.keras.Model and tf.estimator.Estimator. The Keras optimizer lives at tensorflow_privacy/privacy/optimizers/dp_optimizer_keras.py. For development, the README gives `git clone https://github.com/tensorflow/privacy`, then `cd privacy` and `pip install -e .` to put the local package on PYTHONPATH. Contributors are asked to follow PEP8 with two spaces, which the README says can usually be handled with `autopep8 -i --indent-size 2 <file>`, and to run `pylint --rcfile=/path/to/the/tf/rcfile <edited file.py>` against TensorFlow's pylint configuration. A Google CLA signature is required for a first pull request, and pull requests adding git submodules are not accepted. The change worth planning around is the 0.9.0 release note: as of that version the repository publishes two PyPI packages, tensorflow-privacy for the training parts and tensorflow-empirical-privacy for the empirical privacy testing parts. If you pinned a pre-0.9.0 install and used anything from the empirical testing side, the import path is the thing to check first, because the code did not disappear, it moved to a different distribution.
The Dense and Embedding restriction is a real boundary
The fast per-example clipping path applies to DP Keras models consisting only of Dense and Embedding layers. Read that as an exclusion, not a starting point. A model with a custom layer, a recurrent stack, an attention block, or any layer that does not fit that description is outside the fast path, and the README does not describe what the fallback looks like for those architectures beyond the general microbatch approach it says the fast implementation removes the need for. So the practical question when evaluating this library is not whether it supports differential privacy, it is whether your architecture is inside the supported set. If it is not, you are back to choosing a microbatch count, which is a tuning parameter that trades memory against the fidelity of the per-example clipping, and the README gives no guidance on how to pick it. That gap is the most likely place for a team to get a privacy claim that is weaker or stronger than they think. There is a second boundary around the tutorials themselves. The README states plainly that the tutorials are maintained carefully but are not part of the API and can change at any time without warning, and that third party code should not import them and expect the interface to stay stable. The research directory is described as less carefully maintained than the tutorials and intended as a convenient archive. Both are fine for learning and reproduction, neither is a dependency you should build on.
Where Opacus differs in approach
The obvious alternative for anyone not committed to TensorFlow is Opacus, the PyTorch differential privacy library. The difference is not cosmetic. Opacus hooks into PyTorch's autograd and module system, which means per-example gradient computation is attached to the framework's own backward pass rather than to a set of optimizers written against TensorFlow's optimizer interface. For a PyTorch team, the choice is between rewriting the training stack in TensorFlow to reach this library's optimizers, or staying in PyTorch and using the tooling built for that framework's execution model. The TensorFlow Privacy README does not discuss cross-framework portability, and the fast clipping result it cites is implemented for Dense and Embedding Keras layers specifically, so there is no claim here that the same speedup transfers to an arbitrary architecture in either framework. If your team is already on TensorFlow and your model is Dense and Embedding, the decision is easy. If your team is on PyTorch, the cost of adopting this library is a framework migration on top of the privacy work.
Maintenance, licensing, and what the release cadence tells you
The repository is not archived and the last push recorded is 2026-08-26. The most recent release is v0.9.0 from 2024-02-14, preceded by v0.8.12 and v0.8.11 in October 2023. The gap between the last release and the last push is worth noting: code is moving on master without a tagged release, so a team that pins to PyPI is on a 2024 snapshot while the repository has continued. That is a normal pattern for a research-adjacent library, but it means you should decide deliberately whether you track releases or a commit. The library is Apache-2.0, which permits commercial and closed-source use and requires preservation of the licence and notices; the README carries a Google LLC copyright notice dated 2019. Nothing here is legal advice, and if you ship a model trained with this library, the licence on the code is separate from whatever obligations attach to the data and the privacy claim you make about the model. The README lists three maintainer contacts for questions that issues cannot answer, which is a reasonable proxy for how much support to expect outside the issue tracker.
Editorial conclusion
Adopt TensorFlow Privacy if you already train in TensorFlow, your model is built from Dense and Embedding layers, and you need an epsilon number you can put in front of a reviewer. Do not adopt it if you are on PyTorch, if your architecture depends on custom layers with per-layer state, or if your privacy requirement is really about not collecting the data in the first place. Before committing, verify three things against your own code: that the installed TensorFlow version is 2.4 or later if you plan to use the Keras optimizer with tf.keras.Model or tf.estimator.Estimator, that every layer in your model is covered by the fast per-example clipping path or that you have budgeted for microbatch tuning, and that the accountant's reported epsilon is computed under the same delta and sampling assumptions your reviewer expects.
Community notes