Polars 2.0 ya está aquí: streaming por defecto y SQL como ciudadano de primera
Polars 2.0 ya está disponible. La librería de DataFrames escrita en Rust y respaldada por Apache Arrow acaba de pegar uno de los saltos más importantes desde su lanzamiento, y lo hace con dos movimientos que redefinen el día a día de cualquier equipo de datos: convertir el streaming engine en el modo por defecto y habilitar out-of-core (spill to disk) de fábrica. Para una startup que hoy monta pipelines analíticos, ETL o features para modelos, eso cambia la ecuación de coste deinfraestructura.
El equipo detrás de Polars (la organización pola-rs, basada en Países Bajos) publicó el lanzamiento el 6 de octubre de 2026 junto con una batería de benchmarks contra DuckDB 1.5.6, DuckDB 2.0 alpha y Apache Arrow DataFusion 54.0.0 sobre instancias AWS c7a.4xlarge y c7a.metal.
Qué cambia realmente en Polars 2.0
El comunicado oficial lista cinco grandes bloques, pero el verdadero impacto para una startup se concentra en tres.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días1. Streaming engine como nuevo default
Hasta Polars 1.x, el motor en memoria era el predeterminado y el streaming había que activarlo manualmente con pl.Config.set_engine_affinity(engine="streaming"). Desde la versión 2.0, llamar a .collect() sobre un LazyFrame usa streaming automáticamente. En términos prácticos: la mayoría de los queries consumen mucha menos RAM y terminan más rápido sin que tengas que tocar una línea de código.
El motivo del salto de versión mayor (1.x → 2.0) es un cambio de contrato: el motor streaming ya no garantiza el orden de filas en operaciones como join, group_by o unpivot. Si una parte de tu lógica depende del orden observable, ahora hay que opt-in explícito con maintain_order=True.
2. Out-of-core (spill to disk) activado por defecto
Polars 2.0 empieza 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 hoy soportan spilling incluyen sort, window functions y la mayoría de expresiones. Joins y group-bys están en el roadmap inmediato.
Esto convierte a Polars en una alternativa real a Spark para datasets que caben en una sola máquina grande. Ya no necesitas un cluster de 50 nodos para procesar 200 GB: una instancia con suficiente RAM y disco NVMe puede absorberlo.
3. SQL como ciudadano de primera clase
Polars llevaba meses expandiendo su cobertura SQL. La versión 2.0 consolida ese trabajo y lo presenta como interfaz oficial. En los benchmarks TPC-H y TPC-DS publicados por el propio equipo, Polars lidera en la mayoría de pruebas frente a DuckDB 1.5.6, DuckDB 2.0 alpha y DataFusion 54.0.0.
Cifras concretas del comunicado, sobre AWS c7a.metal (192 vCPUs, 384 GB RAM):
- Polars escala de 16 a 192 vCPUs siendo 3.8x más rápido en TPC-H y 2.2x 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 s 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: github.com/pola-rs/polars-2.0-benchmark.
Las otras novedades que importan menos (pero también)
- Nuevo dtype
Map: Polars ahora soporta ArrowMapTypede forma nativa, en vez de representarlo comoList(Struct)como hacía antes. Es un cambio útil si trabajas con datos clave-valor, configuraciones o atributos de usuarios en formato diccionario. - Polars más estricto: errores que antes aparecían 20 minutos dentro de un pipeline ahora fallan arriba. La función
collect_schema()permite a un agente de IA validar la estructura de un query sin materializar datos. Esto está pensado explícitamente para flujos de AI-driven development, donde un agente itera cientos de queries y necesita feedback rápido. - Roadmap próximo: mejor out-of-core, mejor escalado en CPU counts altos, Polars Cloud (motor distribuido) y GeoPolars (geoespacial).
Por qué esto te cambia el coste como startup
El movimiento de Polars 2.0 se inscribe en una tendencia más amplia que el medio dev.todocumentó en mayo de 2026: la «renaissance single-node». En lugar de escalar hacia afuera con clusters de Spark, los equipos están escalando hacia arriba en máquinas únicas gracias a tres tendencias simultáneas:
- Hardware: laptops con 12+ cores, NVMe a multi-gigabyte/s, hasta 128 GB de RAM; VMs en la nube con cientos de cores por una fracción del coste de un cluster.
- Software: ejecución vectorizada sobre Apache Arrow con SIMD (AVX-512, Neon) y spilling a disco maduro.
- IPC zero-copy entre Python, Rust y C++: el famoso «impuesto de serialización» que consumía hasta 80% del tiempo de un query en arquitecturas tradicionales se reduce a casi cero.
El resultado es que una startup con un dataset de cientos de gigabytes ya no necesita un cluster de Spark para procesarlo. Le basta con una instancia gorda (tipo c7a.metal o un MacBook Pro con 96 GB de RAM) y DuckDB, Polars o DataFusion.
Qué significa esto para tu startup
Si estás eligiendo stack de datos hoy, Polars 2.0 cierra varias discusiones que hace un año eran obvias.
Acciones concretas que puedes tomar esta semana:
- Migrar tus pipelines pequeños a streaming: si tienes un script que llama
.collect()sobre unLazyFrame, simplemente actualiza a Polars 2.0 y empieza a beneficiarte del nuevo default sin tocar código. Hazlo primero en un entorno de staging y mide memoria consumida. - Probar SQL como interfaz: Polars 2.0 ya soporta SQL como ciudadano de primera clase. Si tu equipo está más cómodo con SQL que con la API de expresiones, ahora puede escribir
SELECT ... FROM polars_scan(...)sin perder rendimiento. Útil para integrar analistas en pipelines de ingeniería. - Reevaluar tu presupuesto cloud: antes de pagar el siguiente mes de EMR o Databricks, mide cuánto te costaría el mismo workload en una sola instancia
c7acon Polars 2.0 + Iceberg. La diferencia puede ser de un orden de magnitud. - Aprovechar el modo estricto para AI agents: si estás construyendo o usando agentes de IA que generan código de datos,
collect_schema()es la pieza que faltaba para que el agente valide su propia salida antes de ejecutarla. Menos loops de prueba-error, menos tokens gastados. - Vigilar Polars Cloud y GeoPolars: si tu cuello de botella actual es pasar de single-node a distribuido sin reescribir en Spark, Polars Cloud puede ser la migración natural. Y si trabajas con datos geoespaciales, mantén GeoPolars en el radar.
Fuentes
- Release of Polars 2.0 (pola.rs)
- Updated PDS-H benchmark results (May 2025) – Polars
- Single-Node Data Engineering: DuckDB, DataFusion, Polars, and LakeSail (dev.to, mayo 2026)
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
