greta writes Bayesian models in R and fits them on TensorFlow

Stan-like models, written as R expressions

greta is an R package for writing statistical models and fitting them by MCMC and optimisation. The framing sentence in the project documentation is that you can write your own model like in BUGS, JAGS and Stan, except that you write models right in R.

That is the whole pitch. BUGS and JAGS use their own modelling language, Stan uses its own, and greta lets you stay in R while describing the same kind of model: stochastic nodes, deterministic nodes, the dependency graph between them, and a sampler or optimiser that runs over that graph.

The other two claims in that sentence are about scale and extensibility. The documentation says it scales well to massive datasets, and that it is easy to extend and build on, which is the argument for a package written as a graph engine rather than a fixed set of model types.

The audience is specific. This is for someone who already knows this class of model and wants to write it in R syntax, not for someone looking for a point and click statistical tool. The repository carries a paper directory, a JOSS badge, a Zenodo DOI badge and a codemeta.json file, which is the paper packaging you would expect from a package built for academic use.

TensorFlow does the sampling, Python is the seam

The architectural decision that defines greta is that the numerical work happens in Python.

greta uses Google's TensorFlow and tensorflow-probability packages under the hood, and the first time you use greta in a session it automatically installs a compatible Python, TensorFlow and TensorFlow Probability via uv. The documentation states that for most users there is nothing extra to install, so library(greta) followed by your first model usually just works.

That convenience has a cost you should price before you commit. An R package that reaches into a Python environment, installs packages into it on first use, and then dispatches model graphs to a TensorFlow backend is not a pure R tool. It also means the failure modes are not the usual R ones: a failed uv install, a network-restricted machine, or a version conflict between the R side and the Python side will produce errors you have never seen before.

The dependency list is specific, which helps. By default it installs TF 2.21.0, TFP 0.25.0 and Python 3.12, and you can choose versions through the deps argument of install_greta_deps() and the greta_deps_spec() helper. The versions are pinned, so reproducibility is a matter of pinning the same set, not of hoping the resolver agrees with you.

Installing the release, the dev build, or a pinned environment

There are three install paths, and the documentation explains each in two sentences.

The release comes from CRAN.

install.packages("greta")

The development version comes from r-universe, and the documentation notes that installing from r-universe is just like installing from CRAN and should be faster and more convenient than installing from GitHub.

install.packages("greta", repos = c("https://greta-dev.r-universe.dev", "https://cloud.r-project.org"))

The third path is GitHub, through remotes.

``` r remotes::install_github("greta-dev/greta") ```

Then there is the Python side, which is the part that is unusual. If you need a conda environment instead, for example on an offline network, or you want to pin specific versions, you use install_greta_deps() and then point greta at that environment with greta_set_python("conda").

So there are two separate configuration decisions: which greta you install, and which Python environment it talks to. The vignettes named in the documentation are the installing dependencies vignette, and the two help pages are ?install_greta_deps and ?greta_set_python.

The repository is set up for a package under active review

The top level of the repository is a good map of how the project is run, and it is more elaborate than a typical analysis package.

There is the standard R package skeleton, with DESCRIPTION, NAMESPACE, R/, man/ for documentation, inst/, tests/ and vignettes/. There is a greta.Rproj file for RStudio, a .lintr configuration, and an air.toml, which is the formatter configuration for the Air R formatter. A .lazytest file suggests lazy loading is configured for the test suite.

Then there is the parts of a project that is also a website and a paper. A pkgdown/ directory builds the documentation site, .netlify holds the hosting configuration, and there is a paper/ directory with a JOSS badge and a Zenodo DOI, plus a codemeta.json file for machine readable metadata. The .EDIT_WEBSITE.md file is the usual marker for text edited on the website rather than in the source.

Two directories stand out. flint/ is a testing framework the project uses, and touchstone/ is a benchmarking and performance regression harness, which is how you keep an MCMC sampler from silently getting slower between versions. A touchstone directory in a statistics package is a good sign about the maintainers' priorities, because the bottleneck in a Bayesian workflow is very often the sampler rather than the model code.

The docs/ directory at the root and the data-raw/ directory, which holds the scripts that build the shipped data, complete the picture.

Version history: long gaps, then a 2026 release

The release history needs reading with care, because the gaps are long.

The listed releases are greta 0.6.0 on 2026-07-21, greta 0.5.0 on 2024-11-13, and greta 0.4.5 on 2024-03-11. The last push was on 2026-10-14 and the repository is not archived.

So the gap between 0.4.5 and 0.5.0 was about eight months, and 0.5.0 sat on CRAN for another year and a half before 0.6.0 arrived in July 2026. This is a package with a large and irregular version number, and the kind of gap you see when a package depends on a fast moving backend, because TensorFlow and TensorFlow Probability both release often and a package built on top of them has to track those releases.

That connection is the honest explanation for the cadence, and it also tells you what an upgrade involves. Moving to a new greta version can mean moving to a new TensorFlow version, which can mean a new Python version and a new set of wheels for your platform. The version pinning facilities described earlier exist precisely because of that.

For a team planning a long-lived analysis, the practical consequence is that the environment is a moving target and your results depend on it. The good practice here is to capture the environment, since greta_deps_spec() and the deps argument exist so you can state exactly what you are running against.

Licensing and the community around the project

The README carries an Apache 2.0 licence badge, and the repository contains both a LICENSE and a LICENSE.md file, so the terms are available to read. The licence field in the project metadata is one GitHub cannot classify, which is a reminder to look at the file rather than at the badge.

The project is not just a package. There is a website at greta-dev.github.io/greta with tutorials, example models, a reference index and a page describing the package documentation, and a dedicated forum at forum.greta-stats.org. The tutorials include a get started article and an example models article, which are the two a new user should read before writing anything.

The community infrastructure is visible in the repository too. CODE_OF_CONDUCT.md is present, CONTRIBUTING.md is present, and there is a .github/ directory for the CI workflows, including an R-CMD-check badge that tracks whether the package passes the standard CRAN checks. There is a Codecov badge for test coverage, and a cran-comments.md file, which is the file maintainers update with the results of their CRAN submission checks.

None of this is unusual for an academic statistics package, and it is the reason the project is safe to adopt for research work. The unusual parts are the Python dependency and the release cadence, and those are the two things to plan around.

Editorial conclusion

greta fits a statistician or ecologist who wants to express a Bayesian model in R rather than in Stan syntax, who prefers an optimiser with a history of using greta over waiting for a C++ toolchain to build, and who is willing to have Python appear in the workflow. It does not fit a team with a hard no-Python policy, an offline machine that cannot reach a package index, or a deployment where the overhead of TensorFlow is unacceptable, since the documentation makes clear that TensorFlow and TensorFlow Probability run underneath every fit. Before adopting it, read the installing dependencies vignette and decide whether the auto installed environment or a conda one suits your setup, confirm you can supply the default versions of TF 2.21.0, TFP 0.25.0 and Python 3.12 or pin your own, and note that the licence file in the repository is the one to check for your organisation.

Frequently asked questions

Official sources

1. greta-dev/greta on GitHub
2. Issues
3. Project website
4. README
5. Releases