Pandas debe extinguirse: por qué migrar a Polars y DuckDB

El «cliff» de Pandas: cuándo tu startup empieza a sufrir

Para los founders que montan pipelines de datos, Pandas suele ser la primera opción en Python. Funciona bien hasta que deja de funcionar, y el momento en que «deja de funcionar» tiene nombre: el Pandas cliff.

En términos concretos, el cliff aparece alrededor de los decenas de GB de datos. Tu laptop empieza a quedarse sin RAM, las operaciones se vuelven lentas y el equipo entra en pánico. La reacción típica es saltar a sistemas distribuidos como Spark, Databricks, Snowflake o Dask.

El problema es que ese salto implica una complejidad enorme: configurar clusters, gestionar infraestructura, pagar licencias y mantener un stack que tu equipo probablemente no necesita.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Medium Data, no Big Data: lo que dice Amazon sobre tus datos

¿Pero realmente necesitas distributed computing? La respuesta corta es: probablemente no.

En 2024, Amazon publicó un paper titulado «Why TPC is not enough: An analysis of the Amazon Redshift fleet», comparando la telemetría real de los clusters de Redshift con los benchmarks teóricos. Los números son elocuentes:

El 94,68% de las tablas en la flota de Redshift contienen menos de 100 GB de datos
El 86,9% de las consultas operan sobre 80 GB o menos
El 86,9% de las queries corren en menos de un segundo (asumiendo 10 nodos a 8 GB/s)

Es decir: la mayoría de las empresas no tiene Big Data. Tiene Medium Data. Y para Medium Data, las soluciones son otras.

Jordan Tigani, fundador de MotherDuck y ex-líder de desarrollo de BigQuery en Google, lo resume así: «Todo el mundo se enfoca en big data, pero la mayoría realmente no tiene big data». Tigani levantó US$47,5M en 2022, según reportó TechTarget, para construir una plataforma híbrida sobre DuckDB que permita a las empresas operar on-premises y hacer burst a la nube cuando lo necesiten.

Polars y DuckDB: los reemplazos que sí rinden

Hay dos alternativas modernas, single-machine, que cierran la brecha entre Pandas y los sistemas distribuidos: Polars y DuckDB.

Polars es una librería de DataFrames escrita en Rust. Mantiene una API similar a Pandas pero con diferencias clave: ejecución paralela nativa, evaluación perezosa (lazy evaluation) e inmutabilidad de los DataFrames, lo que promueve un estilo funcional y previene modificaciones accidentales. Polars está basado en Apache Arrow y aplica automáticamente optimizaciones de query al construir el plan de ejecución, según documenta GeeksforGeeks.

DuckDB es, en palabras de sus creadores, «el SQLite de analytics»: una base de datos analítica in-memory que corre SQL directamente sobre archivos CSV, Parquet o DataFrames de Python. Permite hacer queries SQL sobre tus datos sin importar infraestructura.

Ambas herramientas resuelven el mismo problema: extraer el máximo rendimiento de una sola máquina, sin necesidad de configurar clusters.

Benchmarks reales: cuánto ahorras en tiempo y dinero

El autor del artículo original sometió a las tres librerías a un benchmark con el 1 Billion Row Challenge: procesar mil millones de filas para calcular min, mean y max de temperaturas por estación meteorológica.

Hardware servidor (32 cores, 128 GB RAM):

Pandas: 4m 28s, 113% CPU, 38,12 GB RAM
Polars: 5,04s, 3.202% CPU, 18,02 GB RAM
DuckDB: 5,19s, 3.174% CPU, 1,93 GB RAM

Hardware laptop (8 cores, 16 GB RAM):

Pandas: 12m 15s, 110% CPU, 15,67 GB RAM + 21 GB swap
Polars: 39s, 765% CPU, 15,22 GB RAM
DuckDB: 47s, 807% CPU, 546 MB RAM

Los números son elocuentes: Polars y DuckDB son entre 50x y 100x más rápidos que Pandas, usando hasta 19x menos memoria. Y se acercan a implementaciones hechas a mano en Java.

El ecosistema no se queda ahí. En el GTC 2026, NVIDIA presentó su stack de datos estructurados con cuDF (DataFrames acelerados por GPU). Según datos publicados en Next Big Future, cuDF es 10x a 150x más rápido que Pandas en CPU, y acelera motores open source como Spark, Presto, DuckDB y Polars. Casos citados por NVIDIA: Nestlé reporta 5x más velocidad y 83% de reducción de costos con IBM watsonx.data + cuDF.

Apache Arrow: la migración sin romper tu código

La barrera más grande para migrar es el costo de reescribir código. La solución se llama Apache Arrow.

Arrow es el formato columnar en memoria que se está convirtiendo en el estándar de facto para datos tabulares. Fue creado por Wes McKinney, el mismo creador de Pandas. Pandas lo soporta desde su versión 2.0, publicada en abril de 2023.

Lo importante: Polars y DuckDB soportan Arrow nativamente. Esto significa que puedes mover DataFrames entre Polars, Pandas y DuckDB sin copiar memoria. La migración es casi «gratis».

El único detalle: cuando creas un DataFrame en Pandas, debes especificar explícitamente dtype_backend="pyarrow" para que use Arrow por defecto. Si no, Pandas sigue usando su representación interna tradicional.

¿Qué significa esto para tu startup?

Si tu equipo de datos está perdiendo horas peleando con la memoria de Pandas, o estás pagando por Snowflake/Databricks cuando tu dataset cabe en una laptop, hay tres movimientos concretos que puedes hacer esta semana.

Audita tu «tamaño real» de datos. El paper de Amazon dice que el 94,68% de las tablas tienen menos de 100 GB. Antes de pagar por infraestructura distribuida, mira cuánto realmente manejas. Probablemente estés en el rango donde una sola máquina potente alcanza, y los benchmarks muestran que esa misma máquina corre Polars o DuckDB en segundos, no en minutos.
Migra por etapas usando Arrow. No reescribas todo de golpe. Empieza leyendo archivos Parquet o CSV con DuckDB y pasando el resultado a Pandas como Arrow DataFrame (dtype_backend="pyarrow"). Obtendrás una mejora inmediata de I/O sin tocar tu código de transformación.
Elige según el perfil de tu equipo. Si tu equipo viene de SQL, DuckDB te va a resultar natural. Si tu equipo piensa en DataFrames y APIs funcionales, Polars es el camino. Prueba ambos en una sola query de producción y mide el impacto antes de comprometerte con una migración mayor.

La conclusión clave: la próxima vez que alguien en tu equipo proponga saltar a Spark o Snowflake «porque Pandas no escala», primero mide cuánto dato manejas realmente. En la mayoría de los casos, una máquina moderna bien aprovechada alcanza, y si no alcanza, ahí están Polars, DuckDB y, para los casos extremos, GPUs con cuDF.