Polars frente a pandas en 2025: la práctica real
Actualizado: 2026-05-03
Polars lleva dos años presentándose como relevo natural de pandas y hasta este año ese relevo era más esperanza que realidad. Con Polars 1.0 publicado en 2024 y la serie 1.x ya estable, el proyecto está en un punto distinto: tiene API congelada, documentación seria, integraciones con el ecosistema de datos y una comunidad con tamaño suficiente para resolver dudas concretas sin esperar al autor original.
Puntos clave
- Polars es 3–10 veces más rápido que pandas en operaciones comunes de agregación, join y filtro sobre datasets de 1–20 GB en parquet.
- El ahorro de memoria es del 40–60 % respecto a pandas para el mismo dataset, gracias a las columnas Arrow nativas.
- La interoperabilidad vía Apache Arrow (coste casi cero de conversión entre ambos) elimina la presión de migrar todo de golpe.
- La diferencia semántica más importante: Polars no tiene índice — todo se hace con joins explícitos sobre columnas.
- Regla práctica: si el dataset pasa de 100 MB o el pipeline se ejecuta en producción diaria, Polars merece la pena.
Qué ha cambiado desde 2023
La primera vez que probé Polars, en 2023, tuve la impresión de que era más rápido pero inmaduro. Faltaban funciones menores, la documentación asumía que venías de Rust, y los mensajes de error eran técnicos. Nada de eso describe la versión de 2025:
- La API 1.x está congelada con un compromiso de compatibilidad hacia adelante claro.
- La documentación tiene ejemplos para cada función comparando con la API equivalente de pandas.
- Los mensajes de error han mejorado sensiblemente.
La otra diferencia importante es la llegada de la API lazy madura. En pandas cada operación se evalúa inmediatamente, lo que impide optimizaciones globales. Polars tiene ejecución diferida por defecto cuando se usa con LazyFrame: defines el grafo de transformaciones, el optimizador reordena y funde operaciones, y la ejecución solo ocurre cuando pides el resultado.
Rendimiento medido, no prometido
Los benchmarks sintéticos de Polars son impresionantes pero ruidosos. Lo que importa es el rendimiento en tareas reales. Los números que he medido con datasets entre 1 y 20 GB en formato parquet son consistentes en una dirección: Polars es entre 3 y 10 veces más rápido que pandas en las operaciones comunes de agregación, join y filtro.
La mejora es mayor cuando la operación incluye agrupaciones grandes o joins sobre varios millones de filas:
- En un pipeline de limpieza diaria de datos de ventas, la migración de pandas a Polars bajó el tiempo de ejecución de 42 minutos a 6.
- En otro pipeline más pequeño de unos 500 MB, la mejora fue de 28 segundos a 9.
El ahorro de memoria también es real. Polars usa columnas Arrow nativas con tipos eficientes, mientras que pandas arrastra el legado de numpy con tipos como object para cadenas. En mis pruebas, Polars usa típicamente entre el 40 % y el 60 % de la memoria que pandas requiere para el mismo dataset.
Interoperabilidad vía Arrow
La pieza que hace que convivir con ambas herramientas sea viable es Apache Arrow. Tanto pandas como Polars pueden leer y escribir Arrow nativamente, y la conversión entre ambos tiene coste cercano a cero gracias a zero-copy.
En la práctica, esto significa que un script puede empezar leyendo datos con pandas si es más cómodo, convertir a Polars para operaciones costosas, y volver a pandas para pasarle el resultado a una biblioteca que solo acepta DataFrame de pandas.
La convertibilidad quita la presión de migrar todo de golpe. En proyectos reales lo que he hecho es migrar los bucles calientes, las partes del código que consumen el 90 % del tiempo, a Polars, y dejar el resto en pandas.
Hay una sutileza con los tipos. Pandas tiene algunos tipos como datetime con zona horaria o los tipos categóricos que no siempre se traducen limpiamente a Polars. En 2025 este rozamiento ha disminuido mucho pero no ha desaparecido.
Dónde pandas sigue ganando
No todo es ventaja para Polars. Tres casos donde pandas sigue siendo mejor:
- El ecosistema científico. statsmodels, scipy y scikit-learn aceptan DataFrame de pandas como entrada estándar. Polars puede convertir con bajo coste, pero el flujo natural sigue siendo pandas.
- Trabajo interactivo en notebooks sobre conjuntos pequeños. Para 10.000 filas la diferencia de rendimiento es imperceptible, y la familiaridad del equipo gana. Imponer Polars para explorar un CSV de 5 MB es ingeniería gratuita.
- Soporte en herramientas de BI. Streamlit, Panel, Dash y la mayoría de entornos de dashboard asumen pandas como formato interno. Polars progresa pero todavía hay casos en los que es ciudadano de segunda.
Patrones que funcionan en producción
Después de migrar varios pipelines he acabado con tres patrones que repito:
- Pipeline ETL con parquet o CSV grandes y transformaciones de agregación y join: Polars gana claramente y merece ser la opción por defecto.
- Análisis exploratorio sobre datasets de unos pocos gigabytes: uso Polars con la API lazy para ajustar la consulta y solo materializo cuando tengo claro qué devolver. Cuando el resultado va a un gráfico o modelo, convierto a pandas.
- Script puntual: donde la simplicidad gana al rendimiento. Pandas sigue siendo la opción por defecto: la inversión de aprendizaje no se amortiza en una semana.
En Python es común ver el patrón:
pl.scan_parquet("ventas.parquet")
.filter(pl.col("fecha") > "2025-01-01")
.group_by("region")
.agg(pl.col("importe").sum())
.collect()Que lee un parquet de forma diferida, filtra, agrupa y ejecuta. Este mismo patrón de ejecución diferida también es lo que hace eficiente el procesamiento de datos para RAG cuando los datasets de evaluación son grandes.
Cómo migrar sin sufrir
La migración progresiva funciona mejor que la migración total. Lo que he visto fallar es equipos que deciden pasar de pandas a Polars en bloque: aprenden dos APIs en paralelo, tropiezan con diferencias semánticas sutiles y acaban frustrados.
La diferencia semántica más importante que atrapa a la gente es que Polars no tiene índice como pandas. En pandas hay operaciones que dependen del índice para hacer alineación entre DataFrames; en Polars todo se hace con joins explícitos sobre columnas. Este cambio de modelo mental es el mayor obstáculo para migrar código pandas maduro.
La segunda diferencia: Polars aplica sus expresiones en contextos, no fuera de ellos. En pandas puedes tomar una serie y hacer operaciones sobre ella en cualquier lugar; en Polars las expresiones viven dentro de select, with_columns, filter, group_by. Esto parece restricción pero hace el código más declarativo y más optimizable.
Cuándo compensa
Mi regla práctica en 2025: si el dataset pasa de 100 MB o el pipeline se ejecuta en producción diaria, migrar a Polars merece la pena. Si el dataset está debajo de ese umbral y el pipeline es exploratorio o puntual, pandas sigue siendo suficiente.
La pregunta que desbloquea la decisión es económica, no técnica: el coste de migrar es el tiempo que el equipo invierte en aprender una API nueva; el beneficio es el tiempo de cómputo ahorrado y la memoria liberada.
Creo que Polars va a acabar siendo la opción por defecto para nuevos proyectos, pero pandas no va a desaparecer. El ecosistema científico tiene demasiada inversión en pandas como para que el relevo sea total. La realidad probable es coexistencia prolongada, con Arrow como puente. Un buen escenario para todos.
