bigfunctions: a governed catalog of BigQuery functions you can call with SQL

Packaging the SQL you keep rewriting

bigfunctions is described as a framework to build a governed catalog of BigQuery functions, and the tagline is that you can supercharge BigQuery with it. The project comes with 150 or more functions built by the community, which you can call directly with no install, or redeploy in your own catalog.

The claim in the README is that you can now perform any advanced data task, be it load, transform, or take actions, by running SQL commands in BigQuery. That is the interesting part of the idea. A function like generating fake data, or sending a message, or calling an external service, is normally a piece of Python you run in a notebook, and a piece of Python you run in a notebook is not something a colleague in the business can use.

Putting the same logic in the warehouse changes that. A function deployed to a BigQuery dataset becomes something a person with a SQL editor can call, and something that a scheduled query can call, and something that the platform team can govern, review, and version.

The word governed is doing work in the description. A catalog is a set of things with owners, with names, and with a definition that can be reviewed, and the framework is the mechanism for building one rather than a pile of scripts.

The project is MIT licensed, written in Python, and not archived, with the last push on 2026-08-23. The releases are v0.36 from 2025-05-15, v0.35 from 2025-05-07, and v0.34 from 2025-04-15, so the release line moves in the zero series and the cadence is regular, a few weeks between versions.

Calling a public function with no install at all

The first thing the README demonstrates is the least effort path, and it is the one that gets people to try the project.

Every BigFunction represented by a YAML file in the bigfunctions folder is deployed in public datasets, and you can then call them directly without any install from your own BigQuery project.

select bigfunctions.eu.faker("name", "it_IT")

That single line is the demo. There is nothing to install, no package to add, no configuration, and no key. The function is addressed by a fully qualified name, with the region in the path and the function name in the last segment, and the arguments are the function's own, here a field name and a locale for the fake data generator.

That last detail is worth pausing on, because the name of a public dataset is a piece of shared infrastructure. The function is qualified by region, so the same logical function may live in more than one place, and the way you address it is a decision you make in your SQL rather than in a config file. For a team that wants to adopt these functions for real, that is a question to answer before you write the query, because the answer determines whether a later change of region breaks your SQL.

The README also links an explorer page for the open BigFunctions, which is where you find out what is actually there before you try to call it. The number 150 or more is the community built catalogue, and the model of the project is that the catalogue grows by contribution rather than by a roadmap.

Deploying a function into your own project

The second path is the one for a team that wants the function in its own project, under its own governance, with its own lifetime.

You deploy any bigfunction in your project with the bigfun command line tool. The function is defined in a YAML file, and the naming convention is a folder of YAML files in the bigfunctions directory, so a function called my_bigfunction lives in a file with that name.

``` sh bigfun deploy my_bigfunction ```

That is the whole deployment step, and it is short enough that the interesting part is what has happened by the time it finishes. The function is a unit of code in a YAML file, and deploying it creates that definition in your BigQuery project, where it becomes a function you can call with the same qualified-name syntax as the public ones.

The value of that arrangement is that the difference between the public path and the private path is only where the function lives. The call site is identical, which means a team can start with the public catalogue, and move the functions they depend on into their own project, without rewriting the SQL that uses them. That is what makes the framework rather than a set of scripts, because the migration path is the part that usually goes wrong.

The README also points at a framework page, which is where the YAML format is documented, and the contribution instructions in the community section describe how to add a function.

The repository is three things: functions, a CLI, and documentation

The top level of the repository shows the shape of the project clearly.

There is a bigfunctions directory holding the function definitions as YAML files, which is both the source of the public catalogue and the set of things you can deploy. There is a bigfun directory, which is the Python package that provides the command line tool. There is a data directory, a docs directory, a use_cases directory, and the mkdocs configuration that builds the documentation site. There is a pyproject manifest, a pre-commit configuration, a yamllint configuration, and a bandit configuration, which is the security linter for the Python code.

That last one is a detail worth noticing. A tool that generates Python and runs it in a warehouse has a very different risk profile from an ordinary library, and running a linter that looks for hardcoded credentials and dangerous calls across the repository is a sensible guard for a project that encourages people to contribute code.

The Python package is named bigfunctions, and the console script it installs is bigfun, which is the same name as the package directory. The runtime dependencies are the Google Cloud client libraries for BigQuery, for the BigQuery connection API, and for storage, plus PyYAML for the definitions, Jinja2 for templating, the MkDocs theme and the awesome nav plugin for the documentation site, Click and the click help colours plugin for the command line, the cryptography library, uv as the package manager, and the Google generative AI client.

That last dependency is the one to notice, because it tells you that some of the functions in the catalogue are implemented by calling a hosted model. A function that runs a model inside your warehouse is a very different thing from a function that computes a checksum, and the catalogue holds both kinds.

The package data configuration includes the templates and the datastore directories, so the CLI ships the scaffolding it needs to generate a new function, and the version is dynamic, derived from the source control tag by setuptools-scm rather than written in the manifest.

Contributing a function, and where the project is

BigFunctions is fully open source, and the contribution routes are laid out in the README in a way that makes the shape of a new function obvious.

To suggest a new function, there is an issue link with a template that is itself named for a YAML file, so the thing you write in the issue is the thing you would add to the repository. That is a good design for a catalogue whose unit is a file: the request for a function and the function are the same artefact.

The other routes are a general issue link, a pull request link with the contributing instructions, a Slack community link, and a request to add a star to the repository.

The final entry in the README is a contributors graph, which is the sort of thing that tells you whether a project is actively growing or is a single maintainer's work with a few patches.

On the practical side, the project needs Python 3.10 or newer, and the documentation is built with the MkDocs theme, which means the guides live in the docs directory and are published to the site linked from the README. There is a use_cases directory as well, which suggests the project is organised around the situations people want to solve rather than only around the functions themselves.

The releases show a steady pace rather than a burst, with three versions in three weeks in the spring of 2025, and the repository has continued to receive pushes since, most recently in August 2026. For a project whose value is the catalogue rather than the code, that is the right shape, because the catalogue is the thing that grows and the tool that deploys it changes rarely.

Editorial conclusion

bigfunctions fits a data team that keeps writing the same ad hoc SQL for loading, transforming, and taking actions, and that wants those operations packaged, documented, and callable by people who do not write SQL. It does not fit a team that cannot accept dependencies on a hosted model provider, since some of the function implementations use one, and it does not fit a warehouse that is not BigQuery. Verify first that the function you need exists in the public catalog or that you are willing to write its YAML definition, that the deployment lands in the dataset and schema your project expects, since the function names are qualified by region, and that the version of the tool you pin matches the BigQuery client libraries you use.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unytics/bigfunctions on GitHub