Polars 2.0.0rc2 has been released. We expect this to be the last release candidate and that Polars 2.0 will go live next week. Install now by running `pip install --pre polars` Link to the full release guide: docs.pola.rs/releases/upgrad…

Profile any Polars query to view its progress and optimize performance with one line change: pl.Config.enable_monitoring() Read the full blog: pola.rs/posts/profile-local-…

Come join us at the second day of Pydata Amsterdam! Learn about our new query profiler and let an agent optimize your queries!

We are happy to announce the first pre-release of Polars 2.0. Polars 2.0 will bring the streaming engine as a default and improves overall strictness of Polars. Give it a spin and share your thoughts. We expect the final Polars 2.0 release in 3-4 weeks. pola.rs/posts/announcing-pol…

The Polars GPU engine now runs on a new streaming backend, built with NVIDIA on their RapidsMPF library. • Queries are no longer bound by GPU memory. Data flows through the query graph in morsels that spill to host memory when device memory gets tight. • The same query scales from one GPU to many. Construct a RayEngine, pass it to .collect(), and there is no cluster to configure and no change to the query itself. Full post: pola.rs/posts/gpu-streaming-…

We've released Python Polars 1.44. Some of the highlights: • Schema evolution when writing to Iceberg sink_iceberg() gained schema_mode="merge", so appending a frame that has a new column extends the table schema instead of raising. Rows written earlier read back as null for that column. • Adaptive rate limiting for cloud I/O Polars now learns how many requests per second S3, GCS, or Azure will actually serve and paces itself to stay under it, so large scans spend less time in retries and are far less likely to fail on throttling. • Correlated subqueries in SQL Subqueries that reference the outer query now work in WHERE, in the select list, and in EXISTS and IN. Blog post: pola.rs/posts/polars-1-44/ Full changelog: github.com/pola-rs/polars/re…

As datasets grow, your tools can limit what analysis is possible. That causes teams to slows down, or forces them to work with samples rather than the whole dataset. BMLL Technologies tackled this issue by migrating their market data workloads to Polars, resulting in a 48x performance improvement. At that speed, a single on-demand machine can aggregate over 1.5 TB of market data in under 4 minutes, removing the need for overnight batch processing infra. Work now fits on a single machine, allowing teams to iterate daily instead of weekly, compounding small wins faster and capturing more basis points. Read the full case study here: pola.rs/posts/case-bmll/

You can turn a column into labeled buckets. With if/elif/else logic takes one chained expression: pl.when().then().otherwise(). Conditions are checked top to bottom, and the first match wins, exactly like Python's if/elif/else. Chain as many .when() branches as you need, and every branch runs vectorized in Rust rather than row by row. Note: a bare string inside then() is read as a column name, so .then("adult") looks for a column called "adult" and raises a ColumnNotFoundError. If you want to fill a string value instead, use pl.lit().

We will ship the first Polars 2.0 release candidate next week. Polars 2.0 will be great for casual Polars users as it will default to the streaming engine, meaning your code will be faster without doing anything. So the first release candidate next week. Give it a spin!

Time series datasets are seldom perfect. Polars gives you a whole menu for repairing them, and the right pick depends on what you need. `fill_null` accepts more than a constant value to fill. `strategy="forward"` carries the last value forward, the natural choice for state that persists until it changes, like a stock ticker. `strategy="backward"` pulls the next known value back, and there is also `"mean"`, `"min"`, `"max"`, `"zero"`, `"one"`, plus a `limit` parameter to cap how many consecutive nulls a fill may bridge. For values that were moving smoothly while a sensor was offline, for example, `interpolate()` draws a straight line between the surrounding points. Combine it with `.over("sensor_id")` and each sensor is filled using only its own history.

When migrating your pandas pipeline to Polars there are several ways to go about it. Read which one works best for you and the tips and tricks to make it successful here: pola.rs/posts/pandas-to-pola…

We've released Polars Cloud client 0.10.0. Some of the highlights: • Stream query results into Python with `sink_batches()` • A new experimental query planner: Miso • Distributed `pl.collect_all()` • Hive-partition aware scans • On-Prem HDFS support Blog post: pola.rs/posts/polars-cloud-0… Full changelog: github.com/pola-rs/polars-cl…

What does it take to serve a month of Polymarket orderbook data, with 16 billion events and 500 GB of Parquet, as a live interactive dashboard? Less than you'd think. We partnered with the Polars Cloud team to take this dataset to production: - Polars Cloud handles the heavy compute; the same code that processes an hour of data on your laptop scales to a full month across a cluster, unchanged - A Dash app serves it as a thin, stateless layer reading query-optimized Parquet - Plotly Cloud handles the ops: machine sizing, Always-On compute, and metered billing And with Dash 4.3, the app doubles as an MCP server. Claude, Cursor, or ChatGPT can connect and query the actual dataset, to answer users' questions. Explore the live dashboard and read the full breakdown 👇 bit.ly/4yMQcOk bit.ly/4wtMlUQ

Aggregating 500GB of compressed parquet with 16,000,000,000 rows to display it in an enterprise-ready Plotly dashboard. We explored a sample of the Polymarket dataset locally on a laptop, and once we got the pipeline like we needed it to be for the visualisations, we scaled it up to its full month size, without changing the query, to Polars Cloud. The results can be viewed on a live dashboard on @plotlygraphs Cloud! Check the dashboard: polars-cloud-demo.plotly.app… And the blog: pola.rs/posts/market-data-to…

We've released Python Polars 1.43. Some of the highlights: • pl.list() Pack a row's columns into a nested list, keeping each column's value as its own element so you get a list[col1.dtype, col2.dtype]. • ewm_sum() and ewm_sum_by() Exponentially weighted moving sums, where recent values count more than older ones. • Faster joins on hive-partitioned data When both sides of a join scan hive-partitioned data, the optimizer now joins only the partitions whose keys can match. Up to 2x faster, with no API change. Blog post: pola.rs/posts/polars-1-43/ Full changelog: github.com/pola-rs/polars/re…

A float column can hold two different kinds of missing: null for a value that is absent, and NaN for arithmetic that had no valid answer (think 0.0/0.0). Polars keeps them strictly separate. fill_null() leaves NaN untouched, and fill_nan() leaves null untouched. is_nan() on a null returns null instead of false, because nullness propagates through operations. And drop_nulls() keeps NaN rows in place. Want one uniform treatment? Convert first, then fill: fill_nan(None) turns every NaN into a proper null, and fill_null(0.0) handles the rest in one go. In the example below, sensor B keeps its NaN after fill_null(), and sensor C reports null for is_nan(). The "both" column shows the two-step fix.

Reading a terabyte dataset from S3 goes fastest on a cluster of small machines, while heavy joins run fastest on one big machine. We benchmarked single node Polars against distributed Polars on the same total vCPUs, RAM and price, and the bottleneck of your query decides the winner. Read the full post here: pola.rs/posts/single-node-vs…

We've been busy in Q2 2026. Read all the highlights in the latest Polars in Aggregate: pola.rs/posts/polars-in-aggr…

Libraries for Your Python Polars Workflows #python opensource.posit.co/blog/202…