plotlars: Polars data frames as Plotly and Plotters charts

A bridge between Polars frames and plotting backends

plotlars exists to remove the gap between data analysis and chart construction. The README describes it as a Rust library that bridges the Polars data analysis library and visualization backends, and the project description is blunter still: it is designed to facilitate the integration between Polars and Plotly.

The value proposition is that a chart is described in terms of the data frame rather than in terms of a trace. You point the plot at columns, and the library works out the traces. The README puts it as allowing developers to focus on data insights rather than the intricacies of plot creation, which is the same argument every dataframe-to-plotting library makes, and the question is whether this one delivers it without dragging in a second mental model.

The two backends are the interesting design decision. Plotly, through the plotly.rs crate, produces interactive HTML based charts. Plotters produces static image output in PNG and SVG. The same plot type, the same frame, the same column selection, two very different destinations, which is what lets a Rust service generate a web dashboard chart and a report image from one code path.

The library is published on crates.io as plotlars, with API documentation on docs.rs, and the licence is MIT. The workspace version is 0.12.6, the Rust edition is 2021, and the minimum supported Rust version is 1.86.0. The author listed in the workspace metadata is Alberto Cebada Aleu. The repository default branch is develop rather than main, which tells you where the work happens.

A support matrix that tells you which backend gets which chart

The README carries a table of plot types, and it is the most useful page in the documentation because it tells you where the gaps are. Each row lists the required parameters, whether the plot supports Facet, whether it supports Group, and then two columns for the backends, Plotly and Plotters, marked Yes or blank.

The plot list covers Array2d, Bar, Box, Candlestick, Contour, Density Mapbox, Heat Map, Histogram, Image, Line, Mesh3D, OHLC, Pie Chart, Sankey Diagram, Scatter 3D, Scatter Geo, Scatter Map, Scatter Plot, Scatter Polar, Surface Plot, Table, Time Series and two subplot grid variants, one regular and one irregular. That is a range comparable to what a plotting library offers, and it is arranged around dataframe columns rather than around geometric primitives.

The required parameters column is where the data model shows through. Bar and Box plots take data, labels and values, Contour takes data plus x, y and z, and Candlestick takes data, dates and the open, high, low and close series. The facet and group columns tell you which plots can be split into panels or grouped into series directly, which for a Polars user is the difference between a one-liner and a manual reshape of the frame.

Not every plot is available everywhere. Array2d is marked as Plotly only, with no Plotters support, and several other rows show the same asymmetry. The table in the documentation available here is cut off partway through the Density Mapbox row, so the full matrix is best read on the project's own page. The pattern is clear enough to plan around: interactive HTML coverage is broader than static image coverage, so a team that needs the same chart in both outputs has to check the matrix first rather than assume parity.

Four crates, with Polars as the data layer

The repository is a Cargo workspace with four members:

[workspace]
members = [
    "crates/plotlars-core",
    "crates/plotlars-plotly",
    "crates/plotlars-plotters",
    "crates/plotlars",
]

The naming explains itself. plotlars-core holds the shared abstractions, plotlars-plotly and plotlars-plotters are the backend implementations, and the plotlars crate is the facade you depend on. The split is what allows the support matrix to differ per backend, since each backend crate can implement the plot types it can actually draw.

Polars itself comes in as a workspace dependency with a specific feature set:

polars = { version = "0.54.4", features = ["lazy", "dtype-categorical", "timezones", "parquet", "strings"] }
plotly = "0.14.1"
plotters = "0.3"

The feature list is the specification of what the library needs from Polars. The lazy feature means the library can work with lazy frames, which is the point of using Polars in the first place. The categorical dtype feature is for axes and legends that group by category, timezones for time series with proper time handling, parquet for reading data files directly, and strings for text handling. If your use case needs a Polars feature outside that list, you will be enabling it yourself in your own manifest, which is a small but real friction point when a plot type depends on something the crate did not turn on.

The other workspace dependencies are small and boring in the way a good library is: bon for builder-style constructors, image for image handling, indexmap and ordered-float for deterministic ordering of keys and float values in maps, and serde and serde_json for serialisation. The determinism that ordered-float and indexmap provide is the kind of detail that matters when chart output is compared between runs.

Where to get it, and what the README does not tell you

The README does not include an installation section or a usage example, so there are no commands to copy and no code to paste. The distribution route is nevertheless clear from the badges and the crate layout: the library is published on crates.io as plotlars, and the API documentation is hosted on docs.rs, which is also listed as the project homepage. For a Rust project, adding plotlars to the dependency list in Cargo.toml and letting Cargo resolve the version is the whole installation story, and the docs.rs pages for each plot type are the usage reference.

What the README leaves out is worth naming, because it affects how you start. There is no worked example of a plot built from a Polars frame, no explanation of how a LazyFrame is passed in and collected, and no guidance on which plot type to pick for a given question. The table of required parameters is the closest thing to a specification. There is also no statement about how the two backends differ in styling, whether the Plotters output can be configured to match a house style, or whether Plotly charts are written out as standalone HTML files, as a bundle, or embedded in a template.

The repository does contain a data directory, and the top level holds a CHANGELOG.md, a SECURITY.md, a .pre-commit-config.yaml and a Cargo.lock, so the project has the release hygiene files you would expect. The docs, however, live on docs.rs rather than in the repository, which means the rendered API docs and the source comments are the only place the details live.

No GitHub releases, a develop branch and a 0.x version number

The release situation is the fact to plan around. The project has no GitHub releases at all, which means there are no tags in the GitHub interface to point a dependency at and no release notes to read there. The crate on crates.io is the distribution channel, and the CHANGELOG.md in the repository is the record of what changed.

The version number tells you where the project is in its own terms. 0.12.6 is a pre-1.0 version, and under the usual Cargo semantics that means the API can still change between minor releases. The default branch is develop, so the code you see on GitHub is ahead of the published crate, and the crates.io version may be several commits or a release or two behind what is in the tree. The last push was on 2026-10-08, so the project is being worked on, but the working branch and the published artefact are different things.

For a library used in a service or a batch job, that means two things. You should pin the version in Cargo.lock rather than tracking a branch, because there is no tag to anchor to. And when you upgrade, the CHANGELOG is where the breaking changes will be described, since there is no release page to read.

The MIT licence is the simplest part of the story. It is recorded in the workspace metadata and in the LICENSE.txt file at the root, with no copyleft obligations, so embedding plotlars in a proprietary product is straightforward on the licensing side.

Where plotlars is the wrong tool

The first wrong-tool case is language. plotlars is a Rust crate that speaks Polars and Rust types. There is no Python binding, and no mention of one, so a team whose data work happens in pandas and Plotly.py has no path in. The README's own framing as a bridge between the Polars library and the Plotly library is a Rust-to-Rust bridge, and reading it as a general integration is a mistake.

The second case is a chart that Plotters cannot draw. The support matrix has blanks in the Plotters column, and Array2d is one of them. If your pipeline must emit a static PNG of a specific chart type, or if your organisation's publishing pipeline only accepts raster images, the static backend is where the gaps bite, and the fact that the interactive backend covers more types does not help you.

The third case is a team that wants maximum control over the output. Against the alternative of using plotly.rs or plotters directly, plotlars saves you from constructing trace objects by hand but constrains you to what the library has modelled. Direct use of plotly.rs gives you every option the Plotly schema offers, including the ones plotlars has not modelled, at the cost of describing the chart yourself in Rust rather than by column name. The same trade appears with plotters directly, where the drawing primitives are all available and the dataframe binding is not.

There is one more constraint that follows from the architecture rather than the feature list. Because the chart is derived from a Polars frame, the data has to be in Polars to begin with. If the data arrives as Arrow, Parquet or CSV, that is fine, since the crate enables the parquet feature and Polars reads CSV natively. If the data arrives in some other in-memory format, the conversion is your problem, and for a one-off chart in a non-Rust service that conversion may cost more than writing the chart directly.

Editorial conclusion

plotlars suits a Rust team that already works in Polars and wants charts generated from a dataframe without hand-building trace objects, and it suits a team that needs static PNG and SVG output from the same code as well as interactive HTML. Before adopting it, check the support matrix in the README for your chart type, since a number of plots are Plotly only and Array2dPlot has no Plotters implementation, and pin the version deliberately, because the project publishes no GitHub releases and develops on the develop branch. If you are in Python rather than Rust, none of this applies, since plotlars is a Rust crate with no Python binding.

Frequently asked questions

Official sources

1. alceal/plotlars on GitHub
2. Issues
3. License: MIT
4. Project website
5. README