Flux: InfluxData's query language, now in maintenance mode

A query language that ships inside InfluxDB but also runs on its own

Flux is described in the README as a lightweight scripting language for querying databases such as InfluxDB and working with data. It is part of InfluxDB 1.7 and 2.0, and it can also be run independently of those products.

That second option is what makes this repository interesting to look at on its own. The tree holds the language definition and an implementation of the language core, and the entry point is a REPL you compile yourself. The README points at a complete specification in `docs/SPEC.md`, which it says contains many examples to start learning Flux.

The users are two groups with different needs. InfluxDB operators scripting dashboards and ad hoc queries are the obvious audience. The other group is engineers embedding Flux in Go programs, since the module path is `github.com/influxdata/flux` and the repository ships a Go package layout rather than a standalone binary only.

The Rust core sits behind Go through a pkg-config wrapper

The build requirements list Go 1.16 or greater with module support, the latest stable Rust and Cargo installed through rustup, and Clang. The Rust is not optional packaging: Flux has a Rust implementation of the language core in `libflux`, and Go talks to it through a C-style interface.

The glue is unusual enough to be worth understanding. The README asks you to install the GNU `pkg-config` utility, then the `pkg-config` wrapper, and the Makefile goes further by exporting a repository-local script as the config tool for every Go build:

export PKG_CONFIG:=$(shell pwd)/pkg-config.sh

The comment above that line explains why: the custom package config makes Go builds invoke the Rust library libflux and build it on the fly. The Makefile also adds a repository-local `bin` directory to `PATH`, so the wrapper resolves ahead of any system version.

The result is a build that needs two toolchains and a C compiler. It is a heavier setup than a pure Go project, and it is the price of keeping the parser and evaluator in Rust.

Building the REPL needs pkg-config on your PATH first

The README gives the install sequence in order, and the order matters because the wrapper shadows the system tool. On Debian and Ubuntu the first step installs Clang and the GNU utility:

$ sudo apt-get install -y clang pkg-config

On macOS with Homebrew the equivalent is `brew install pkg-config`. Next comes the wrapper itself, fetched with `go get github.com/influxdata/pkg-config`, and then the GOBIN directory is put on the PATH so the wrapper wins over `/usr/bin/pkg-config`:

$ export PATH=${GOPATH}/bin:${PATH}

The README asks you to verify the result with `which -a pkg-config`, which should show the Go bin directory ahead of the system path. Once that is right, the REPL is two commands:

$ go build ./cmd/flux
$ ./flux --enable-suggestions

There is a documented escape hatch for projects where the wrapper does not work: set `PKG_CONFIG` explicitly and build with `go install ./cmd/flux`, then run the binary as `${GOPATH}/bin/flux repl`. Inside the REPL you can evaluate any Flux expression, and typing `@` followed by a filename loads a file directly.

Keyword arguments and pipes define how Flux programs read

The README's syntax examples make one thing clear quickly: Flux functions are called with keyword arguments, never positionally, and data moves through a program with the pipe operator.

    import "math"
    math.pow(x: 5.0, y: 3.0) // 5^3 = 125
    add = (a, b) => a + b
    add(a: 5.5, b: 2.5) // 8.0

The last line shows the type system at work. Functions are polymorphic, so integers and floats both work, but the same function called with a mix of the two is a type error, which means the language is statically typed even though it looks loose.

Built-in types cover booleans, ints, floats, strings, durations such as `1h5m`, time literals like `2018-10-10T10:05:00` interpreted in the default timezone, arrays and objects. The pipeline shape is visible in the same examples: a source such as `from(bucket:"telegraf/autogen")` is bound to an identifier, then filtered and windowed with calls like `range(start: -5m)` and `aggregateWindow(every: 1m, fn: mean)`, and each stage is chained with `|>`.

Against a classic SQL query, the difference is real rather than cosmetic. SQL describes a result set declaratively, while a Flux script is a sequence of transformations over records, closer to a small program with intermediate bindings you can reuse. That suits exploratory work, and it costs you the familiar query plan.

Editing the stdlib means running go generate before anything else

The repository is not a pure Go codebase, and the contributor workflow reflects that. The README says that if you modify any Rust code, you need to force Go to rebuild the library:

$ go generate ./libflux/go/libflux

If you create or change any Flux function, you must rebuild the stdlib and tell Go that libflux has to be rebuilt as well:

$ go generate ./stdlib ./libflux/go/libflux

Formatting is the third step, and the README asks for `go fmt` so new code sits well next to the existing style:

$ go fmt ./stdlib/universe/

The Makefile encodes those prerequisites as file dependencies rather than leaving them to memory. Generated targets include `stdlib/packages.go`, `internal/fbsemantic/semantic_generated.go` and `libflux/go/libflux/buildinfo.gen.go`, and the flatbuffers semantic schema is regenerated with `flatc --rust`. In other words, the semantic definition is shared between a Go file and a Rust file, and a change to the schema has to travel to both sides.

That coupling is the main cost of contributing. A change to the standard library is not a Go edit, it is a Rust and Go edit with a generation step in the middle.

The README says Flux is in maintenance mode with a community fork

The most important line in this repository is the warning at the top of the README. InfluxData still supports Flux, but states plainly that it is not doing active development on it and is not adding any new features. What remains are security patches and work on critical defects through the maintenance period.

Attention has moved to the InfluxDB 3.0 engine and its associated products, namely Cloud Serverless, Cloud Dedicated, Clustered and Edge. The README also points to a community owned fork of Flux where active development is happening, at the InfluxCommunity organisation.

The repository itself is not archived, and the last push was on 2026-10-21, shortly after a v0.201.0 release on 2026-10-14. The preceding releases are v0.200.0 on 2026-04-01 and v0.199.0 on 2025-12-12, which shows the version line still advances even as the feature work stops.

So the useful framing is not that Flux is dead, but that it is frozen in place while its ecosystem moves elsewhere. Anyone adopting it for a multi-year platform should read the fork's status first.

MIT licensing, a large dependency surface and the choice between SQL and a script

Flux is licensed under the MIT licence, with the licence text in the `LICENSE` file at the root. That is permissive for commercial use and modification, and the obligation that survives is the licence notice itself, which your own counsel should confirm against the rest of your stack.

The dependency list in `go.mod` is broad, because Flux is designed to query more than one kind of store. It pulls in drivers for BigQuery through `bonitoo-io/go-sql-bigquery`, Snowflake through `github.com/influxdata/gosnowflake`, Azure through the `azcore` and `azidentity` packages, Bigtable through `cloud.google.com/go/bigtable`, plus MySQL, SQLite, SQL Server, PostgreSQL, Vertica and SAP HANA drivers, alongside Kafka, MQTT, Arrow and Prometheus packages. Arrow support appears as a separate `arrow/` directory in the tree.

The alternative approach to writing queries against a time series database is SQL, which most databases already accept and which most BI tools and ORMs already speak. The real difference is that Flux gives you a scripting language with reusable bindings and pipeable transformations, while SQL stays declarative and constrained to what the engine plans. If your team already runs the database through SQL tooling, Flux adds a second language to learn rather than removing one.

Editorial conclusion

Teams already running InfluxDB 1.7 or 2.0 who need to script queries in Go or embed Flux in their own tooling can keep using influxdata/flux as-is, because the README still promises security patches and fixes for critical defects through the maintenance period. New projects, and anyone planning a long-lived internal scripting language, should look at the community fork the README points to rather than building on this repository. Before committing, check that your InfluxDB version still ships Flux, confirm the community fork covers the features you need, and read docs/SPEC.md, since the specification rather than the README is the authoritative description of the language.

Frequently asked questions

Official sources

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