Polars lleva dos anios presentandose como relevo natural de pandas y hasta este anio ese relevo era mas esperanza que realidad. Con Polars 1.0 publicado en 2024 y la serie 1.x ya estable, el proyecto esta en un punto distinto: tiene API congelada, documentacion seria, integraciones con el ecosistema de datos y una comunidad con tamanio suficiente para resolver dudas concretas sin esperar al autor original. Este post recoge lo que he aprendido usandolos en paralelo durante los ultimos meses en trabajos de exploracion, pipelines ETL y scripts de analisis ad hoc.
Que ha cambiado desde 2023
La primera vez que probe Polars, en 2023, tuve la impresion de que era mas rapido pero inmaduro. Faltaban funciones menores, la documentacion asumia que venias de Rust, y los mensajes de error eran tecnicos. Nada de eso describe la version de 2025. La API 1.x esta congelada con un compromiso de compatibilidad hacia adelante claro, la documentacion tiene ejemplos para cada funcion comparando con la API equivalente de pandas, y los mensajes de error han mejorado sensiblemente cuando la operacion es invalida.
La otra diferencia importante es la llegada de la API lazy madura. En pandas cada operacion se evalua inmediatamente, lo que impide optimizaciones globales. Polars tiene ejecucion diferida por defecto cuando se usa con LazyFrame: defines el grafo de transformaciones, el optimizador reordena y funde operaciones, y la ejecucion solo ocurre cuando pides el resultado. En conjuntos de datos moderados esto traduce en mejoras medibles, y en conjuntos grandes la diferencia se vuelve enorme.
Rendimiento medido, no prometido
Los benchmarks sinteticos de Polars son impresionantes pero ruidosos. Lo que importa es el rendimiento en tareas reales. Los numeros que he medido en los ultimos meses, con datasets entre 1 y 20 GB en formato parquet, son consistentes en una direccion: Polars es entre 3 y 10 veces mas rapido que pandas en las operaciones comunes de agregacion, join y filtro.
La mejora es mayor cuando la operacion incluye agrupaciones grandes o joins sobre varios millones de filas. En un pipeline de limpieza diaria de datos de ventas que tengo, la migracion de pandas a Polars bajo el tiempo de ejecucion de 42 minutos a 6. En otro pipeline mas pequenio, de unos 500 MB, la mejora fue menos espectacular: de 28 segundos a 9. Hay un umbral bajo del cual pandas es suficiente; por encima, Polars gana claramente.
El ahorro de memoria tambien es real. Polars usa columnas Arrow nativas con tipos eficientes, mientras que pandas sigue arrastrando el legado de numpy con tipos como object para cadenas. En mis pruebas, Polars usa tipicamente entre el 40% y el 60% de la memoria que pandas requiere para el mismo dataset. Si la maquina estaba al limite con pandas, con Polars cabe.
Interoperabilidad via 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 conversion entre ambos tiene coste cercano a cero gracias a zero-copy. En la practica esto significa que un script puede empezar leyendo datos con pandas si es mas comodo, 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 es importante porque quita la presion de migrar todo de golpe. En proyectos reales lo que he hecho es migrar los bucles caliente, las partes del codigo que consumen 90% del tiempo, a Polars, y dejar el resto en pandas. El coste de convertir entre ambos formatos es despreciable comparado con la ganancia de rendimiento en las partes caliente.
Hay una sutileza con los tipos. Pandas tiene algunos tipos como la serie datetime con zona horaria o los tipos categoricos que no siempre se traducen limpiamente a Polars. Para estos casos hay que hacer conversion explicita o aceptar que el tipo pierde informacion al cruzar la frontera. En 2025 este rozamiento ha disminuido mucho pero no ha desaparecido.
Donde pandas sigue ganando
No todo es ventaja para Polars. El primer caso donde pandas sigue siendo mejor es el ecosistema cientifico: statsmodels, scipy y scikit-learn aceptan DataFrame de pandas como entrada estandar. Polars puede convertir con bajo coste, pero el flujo natural sigue siendo pandas.
El segundo es el trabajo interactivo en notebooks sobre conjuntos pequenios. 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 ingenieria gratuita.
El tercero es el soporte en herramientas de BI. Streamlit, Panel, Dash y la mayoria de entornos de dashboard asumen pandas como formato interno. Polars progresa pero todavia hay casos en los que es ciudadano de segunda.
Patrones que funcionan en produccion
Despues de migrar varios pipelines he acabado con tres patrones que repito. El primero es el pipeline ETL donde la lectura y escritura son parquet o CSV grandes y las transformaciones son agregaciones y joins. Aqui Polars gana claramente y merece ser la opcion por defecto.
El segundo es el analisis exploratorio sobre datasets de unos pocos gigabytes. Uso Polars con la API lazy para ajustar la consulta y solo materializo cuando tengo claro que devolver. Cuando el resultado va a un grafico o modelo, convierto a pandas.
El tercero es el script puntual, donde la simplicidad gana al rendimiento. En estos casos pandas sigue siendo la opcion por defecto: la inversion de aprendizaje no se amortiza en una semana.
En Python es comun ver el patron 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.
Como migrar sin sufrir
La migracion progresiva funciona mejor que la migracion 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 semanticas sutiles, y acaban frustrados. Lo que funciona es identificar las tres o cuatro queries mas caras del pipeline, reescribirlas en Polars usando LazyFrame, medir el ahorro, y solo entonces decidir si migrar el resto.
La diferencia semantica mas importante que atrapa a gente es que Polars no tiene indice como pandas. En pandas hay operaciones que dependen del indice para hacer alineacion entre DataFrames; en Polars todo se hace con joins explicitos sobre columnas. Este cambio de modelo mental es el mayor obstaculo para migrar codigo pandas maduro.
La segunda diferencia que vale la pena mencionar es que 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 restriccion pero hace el codigo mas declarativo y mas optimizable.
Cuando compensa
Mi regla practica en 2025 es: si el dataset pasa de 100 MB o el pipeline se ejecuta en produccion diaria, migrar a Polars merece la pena. Si el dataset esta debajo de ese umbral y el pipeline es exploratorio o puntual, pandas sigue siendo suficiente. Si el equipo no tiene tiempo para aprender API nueva, pandas. Si el coste computacional es visible en la factura de la nube, Polars.
La pregunta que desbloquea la decision es economica, no tecnica. El coste de migrar es el tiempo que el equipo invierte en aprender una API nueva. El beneficio es el tiempo de computo ahorrado y la memoria liberada. Para un equipo pequenio con un pipeline critico, la cuenta sale rapido. Para un equipo grande con muchos pipelines pequenios, menos.
Creo que Polars va a acabar siendo la opcion por defecto para nuevos proyectos en cinco anios, pero pandas no va a desaparecer en ese periodo. El ecosistema cientifico tiene demasiada inversion en pandas como para que el relevo sea total. La realidad probable es coexistencia prolongada, con Arrow como puente. Lo que me parece un buen escenario para todos.
