Polars 2.0 - Out-of-Core per Default und SQL als Erstklassiger Bürger

Das Polars-Team hat Version 2.0 seines Data-Frameworks veröffentlicht — und obwohl der Major-Bump ursprünglich keine große Feature-Release sein sollte, steckt ordentlich Substanz drin: Out-of-Core-Support ist jetzt standardmaeszig aktiviert, SQL wird als gleichberechtigter Bürger behandelt, ein neuer Map-Dtype kommt dazu und die Kern-Engine wurde vielfach beschleunigt.

Streaming-Engine und Spill-to-Disk als Standard

Die groeszte Auswirkung: collect auf einem LazyFrame nutzt jetzt defaultmaeszig die Streaming-Engine — mit spürbaren Vorteilen bei Speicher und Performance auf den meisten Queries. Der Haken, der den Major-Bump nötig machte: Die Streaming-Engine garantiert bei Operationen wie join, group_by oder unpivot keine Zeilenreihenfolge mehr; wer die braucht, setzt explizit maintain_order=True. Out-of-Core-Spilling greift ab rund 80 Prozent RAM-Auslastung, standardmaeszig mit 64 GB Disk-Budget. Sortierungen, Window-Functions und viele Expressions können damit bereits auf Platte ausweichen; Joins und Group-Bys folgen auf der Roadmap.

SQL-Benchmarks gegen DuckDB und DataFusion

Polars 2.0 setzt bei SQL voll auf Abdeckung — und liefert Zahlen nach: Auf TPC-H- und TPC-DS-abgeleiteten Benchmarks (c7a.4xlarge mit 16 vCPUs, c7a.metal mit 192 vCPUs) führt Polars gegen DuckDB 1.5.6, DuckDB 2.0 Alpha und DataFusion 54.0 in fast allen Messungen. Bei SF100 auf der kleinen Maschine braucht Polars für TPC-DS 85,83 Sekunden Summenlaufzeit gegenüber 112,70 (DuckDB 1.5.6) und 198,48 (DataFusion). DataFusion timte auf q72/q67 aus und rannte bei q18 in Speicherprobleme. Ein Wermutstropfen: Bei 192 Threads hat Polars einen konstanten Overhead, der kleine Datenmengen bremst — auf 32 Threads begrenzt gewinnt es hingegen durchweg. Das Team verspricht Abhilfe im nächsten Release, plus künftig GeoPolars und verteiltes Computing via Polars Cloud.

Bemerkenswert ist auch das Argument für mehr Strenge: Fehler sollen früh und laut auftreten, nicht 20 Minuten in eine Pipeline hinein. Mit collect_schema() können Agenten und Menschen Schema-Probleme validieren, bevor Daten materialisiert werden — laut Polars genau das, was KI-getriebene Entwicklung schneller macht.

Link: Polars Blog