Pandas se ahoga en los 100 GB y Polars y DuckDB le comen el terreno
Un análisis de la flota de Redshift de Amazon sugiere que casi nadie tiene big data: el 94,68% de las tablas baja de 100 GB, un terreno que ya cubren herramientas de una sola máquina.
Un post de Eddie Atkinson sostiene que Pandas debería extinguirse —la librería de dataframes de Python, no el oso— y que la salida habitual cuando se agota, Spark, Databricks, Snowflake o Dask, llega demasiado pronto. Su tesis: hay un hueco entre el muro de Pandas y la escala en la que un sistema distribuido se justifica de verdad, y ese hueco lo ocupan Polars y DuckDB.
El muro está en los 100 GB
Describe la ruta típica de adopción: se empieza en Excel, se salta a Pandas en el rango de los GB, la cosa aguanta hasta las decenas de GB y ahí aparecen los problemas de memoria, el cálculo lento y una API que califica de barroca. La respuesta tradicional es pasar a una herramienta "de verdad", con el precio que eso tiene. Atkinson sostiene que la mayoría de cargas no justificarán nunca esa complejidad añadida y que quienes las venden son balas de plata bien comercializadas.
El respaldo son los datos de flota que Amazon publicó en 2024 en el artículo Why TPC is not enough: An analysis of the Amazon Redshift fleet. Con dos supuestos —1 KB por fila de media y clústeres de diez máquinas leyendo a 8 GB/s desde S3— el autor calcula que el 94,68% de las tablas de la flota Redshift ocupan menos de 100 GB y que el 86,9% de las consultas operan sobre 80 GB o menos. Ese 86,9% sale de sumar las consultas que tardan menos de un segundo: diez máquinas a 8 GB/s durante un segundo son 80 GB. El propio autor avisa de que la cifra de 8 GB/s viene de un benchmark anticuado y de que el supuesto de 1 KB por fila es optimista; aun asumiendo 10 KB por fila, la tabla se queda en 1 TB. Jordan Tigani, de MotherDuck, hizo su propio análisis del conjunto, con el matiz de que MotherDuck vende hosting de DuckDB.
La conclusión que saca es que la mayoría de la gente no tiene big data ni lo tendrá: tiene problemas de datos medianos.
Polars y DuckDB, y el reto de los mil millones de filas
Las alternativas que propone son Polars, una librería de dataframes escrita en Rust con una API que resulta familiar a quien viene de Pandas, y DuckDB, una base de datos analítica en memoria que describe como el SQLite de la analítica.
Para compararlas tira del reto de los mil millones de filas, que pedía el programa Java más rápido capaz de calcular mínimo, media y máximo de un CSV de mil millones de filas con datos de estaciones meteorológicas. La implementación aceptada más rápida tardó 1,5 segundos. El reto original corría sobre un Hetzner AX161 con 32 núcleos y 128 GB de RAM con Debian 12; el autor no tenía acceso a bare metal y replicó la configuración en una m7a.8xlarge de AWS, también con Debian 12 y CPU AMD, algo que él mismo admite que puede afectar a la reproducibilidad. En sus pruebas omite la serialización de salida que pide el reto, porque el formato no es estándar y no le parecía una medida relevante de las librerías.
El código de la versión con Pandas es el de siempre: leer el CSV, agrupar por estación y agregar mínimo, media y máximo. Atkinson no llega a publicar en esa entrada los tiempos de Polars ni de DuckDB, así que la comparación numérica queda pendiente y de momento solo queda el argumento.
Lo que sí deja claro es por dónde empezar: medir cuánto ocupan los datos antes de montar un clúster para moverlos.
