martes, 6 de octubre de 2026

diarioempresas

IBEX 3519.434,50▲ +0,70%EuroStoxx 506276,05▲ +0,54%S&P 5007840,40▲ +0,85%€/$1,1271▲ +0,43%Brent98,47▼ -1,84%Bitcoin76.517▲ +0,10%
Última hora

Polars 2.0 activa el streaming por defecto y el SQL nativo

Polars 2.0 ya está disponible con streaming por defecto y out-of-core activado, lo que reduce el uso de RAM y mejora el rendimiento en pipelines analíticos.

Marta Uriarte Elizondo
Marta Uriarte Elizondo
· 3 min de lectura

La librería de DataFrames escrita en Rust lanza la versión 2.0 con el motor streaming como modo predeterminado y out-of-core activado de fábrica, lo que reduce el consumo de RAM en pipelines analíticos.

La organización pola-rs, con sede en Países Bajos, ha publicado Polars 2.0, la nueva versión mayor de su librería de DataFrames escrita en Rust y respaldada por Apache Arrow. El lanzamiento, que según publica ecosistemastartup.com llega acompañado de benchmarks frente a DuckDB y DataFusion, introduce dos cambios que afectan directamente a los equipos de datos: el motor streaming pasa a ser el modo por defecto y el spill to disk (out-of-core) queda habilitado de fábrica.

Hasta la versión 1.x, el motor en memoria era el predeterminado y el streaming requería activación manual mediante pl.Config.set_engine_affinity(engine="streaming"). Desde ahora, llamar a .collect() sobre un LazyFrame usa streaming automáticamente. En la práctica, la mayoría de consultas consumen menos RAM y se ejecutan más rápido sin modificar el código. El salto de versión mayor responde a un cambio de contrato: el motor streaming ya no garantiza el orden de filas en operaciones como join, group_by o unpivot. Si la lógica depende del orden observable, hay que activar maintain_order=True de forma explícita.

El out-of-core comienza a derramar datos a disco cuando el consumo de RAM supera aproximadamente el 80% de la capacidad del sistema, con un presupuesto de disco por defecto de 64 GB. Las operaciones que ya soportan spilling incluyen sort, window functions y la mayoría de expresiones; los joins y group-bys están en el roadmap inmediato. Esto convierte a Polars en una alternativa a Spark para datasets que caben en una sola máquina grande, según el comunicado.

La versión 2.0 también consolida SQL como interfaz oficial. En los benchmarks TPC-H y TPC-DS publicados por el equipo, Polars lidera la mayoría de pruebas frente a DuckDB 1.5.6, DuckDB 2.0 alpha y Apache Arrow DataFusion 54.0.0. Sobre instancias AWS c7a.metal (192 vCPUs, 384 GB RAM), Polars escala de 16 a 192 vCPUs siendo 3,8 veces más rápido en TPC-H y 2,2 veces más rápido en TPC-DS (medido por suma de tiempos). En la misma comparación, DuckDB 1.5.6 logra 3,2x y 1,9x; DuckDB 2.0 alpha, 2,2x y 1,5x; DataFusion, 1,7x y 1,0x.

DuckDB 1.5.6 todavía obtiene ventaja en datasets pequeños cuando Polars corre con sus 192 hilos. El equipo identificó un overhead de paralelización y recomienda limitar Polars a 32 cores en esos casos, hasta resolverlo en la próxima release. En un benchmark previo del propio Polars (mayo de 2025, PDS-H sobre c7a.24xlarge, SF-100), el motor streaming de Polars 1.30.0 completó el suite en 23,94 segundos frente a 19,65 s de DuckDB 1.3.0 y 152,27 s del motor in-memory de Polars. Dask quedó en 548,52 s y PySpark 4.0.0 en 312,43 s. El repositorio con la metodología es público en github.com/pola-rs/polars-2.0-benchmark.

Entre las novedades menores, Polars 2.0 incorpora el nuevo dtype Map, que soporta Arrow MapType de forma nativa en lugar de representarlo como List(Struct), y añade mayor estrictez en la detección de errores.

Marta Uriarte Elizondo

Escrito por

Marta Uriarte Elizondo

Redactora

Graduada en ADE por la Autónoma y emprendedora frustrada (dos veces). Coleccionista de pitch decks, cafetera y optimista pese a las estadísticas; en Diario Empresas firma las pymes y las startups.