El problema: httpfs ignora tus variables de entorno

Si trabajas con DuckDB y la extensión httpfs para leer Parquet remotos, CSVs desde S3 o cualquier recurso HTTP, probablemente asumes que las variables de entorno HTTP_PROXY y HTTPS_PROXY funcionan igual que en cualquier otra herramienta. Curl las respeta. wget las respeta. Python requests las respeta. Node.js las respeta.

DuckDB no.

Me he encontrado con esto trabajando en un entorno corporativo con proxy obligatorio. Tenía un script que leía ficheros Parquet desde Google Cloud Storage usando httpfs, y simplemente no funcionaba. Sin error claro, sin timeout descriptivo, solo silencio. Mientras tanto, un curl al mismo recurso con las mismas variables de entorno devolvía los datos sin problema.

Toda consulta empieza con un plan. Toda consulta lenta probablemente empieza con uno malo. Y más a menudo de lo que crees, las estadísticas son las culpables.

Pero ¿cómo funciona realmente? PostgreSQL no ejecuta la consulta para averiguarlo — estima el coste. Lee datos precalculados de pg_class y pg_statistic y hace los cálculos para encontrar la ruta más barata hacia tus datos.

En el escenario ideal, los números que lee son precisos y obtienes el plan que esperas. Pero cuando están desactualizados, la situación se descontrola. El planificador estima 500 filas, planifica un nested loop, y se encuentra con 25,000. Lo que parecía un plan óptimo se convierte en una falla en cascada.

Últimamente estoy trabajando bastante con DuckDB, y una de las cosas que más me interesan es entender cómo optimizar el rendimiento según el formato de archivo que estemos usando.

No es lo mismo trabajar con Parquet, con CSV comprimido, o con CSV descomprimido. Y las diferencias de rendimiento pueden ser dramáticas.

Vamos a revisar las optimizaciones clave que hay que tener en cuenta cuando trabajamos con diferentes formatos de archivo en DuckDB.

Amazon ha dado un paso importante en el mundo de la inteligencia artificial con el lanzamiento de S3 Vectors, el primer servicio de almacenamiento en la nube con soporte nativo para vectores a gran escala. Esta novedad promete reducir hasta un 90% los costes de subida, almacenamiento y consulta de datos vectoriales.

¿Qué son los vectores y por qué nos importan?

Los vectores son representaciones numéricas de datos no estructurados (texto, imágenes, audio, video) generados por modelos de embedding. Son la base de las aplicaciones de IA generativa que necesitan encontrar similitudes entre datos usando métricas de distancia.

Hace unos meses, cuando Anthropic lanzó su protocolo MCP (Model Context Protocol), sabía que íbamos a ver integraciones interesantes entre LLMs y bases de datos. Lo que no esperaba era ver algo tan pulido y funcional como AgentHouse de ClickHouse tan pronto.

Tengo planificado probar esta demo en breve, pero ya solo leyendo sobre ella me parece fascinante la idea de poder preguntarle a una base de datos cosas como “¿cuáles son los repositorios más populares de GitHub este mes?” y obtener no solo una respuesta, sino visualizaciones automáticas.

Apache Iceberg v3: Revolución en Datos Geoespaciales para el Analytics Moderno

La reciente ratificación de la especificación Apache Iceberg v3 marca un hito significativo en el ecosistema de datos abiertos, especialmente en el ámbito de los datos geoespaciales. Esta actualización no solo consolida a Iceberg como el estándar líder en formatos de tabla abiertos, sino que introduce capacidades geoespaciales nativas que prometen transformar cómo manejamos datos de ubicación y mapeo a gran escala.