Tag: Databases

On August 26th, Mark Raasveldt and Hannes Mühleisen published a very short note on the DuckDB blog: DuckLabs, the company behind DuckDB, is becoming a subsidiary of Amazon Web Services. The deal closes in early September.

I read it more carefully than usual because at CARTO we’ve been using DuckDB for a relatively short time, and I’ve written here about file formats and performance and about the httpfs proxy mess. When you adopt a piece of software in production and months later a hyperscaler buys it, the least you can do is sit down and read the fine print.

El 26 de agosto, Mark Raasveldt y Hannes Mühleisen publicaron una nota muy breve en el blog de DuckDB: DuckLabs, la empresa detrás de DuckDB, pasa a ser una filial de Amazon Web Services. La operación se cierra a principios de septiembre.

Lo he leído con más atención de la habitual porque en CARTO llevamos relativamente poco tiempo usando DuckDB, y yo mismo he escrito aquí sobre formatos de archivo y rendimiento y sobre el lío de httpfs detrás de un proxy. Cuando adoptas una pieza en producción y meses después la compra un hiperescalador, lo mínimo es sentarse a mirar la letra pequeña.

En abril de 2021 hice mi primer commit en el monorepo de la plataforma cloud-native de CARTO. Era el PR número 9, un docker-compose. Cinco años después he mirado hacia atrás con calma y me he encontrado con unos 450 commits, unos 447 pull requests y presencia en prácticamente todos los servicios del repositorio.

Lo interesante no son las cifras. Lo interesante es que, revisando ese historial, aparece un hilo conductor que yo mismo no había identificado del todo: he pasado media década conectando la plataforma a data warehouses ajenos. Seis proveedores distintos —BigQuery, Snowflake, Redshift, Databricks, Oracle y PostgreSQL—, cada uno con su propio modelo de credenciales, su pooling, sus timeouts y sus mensajes de error.

In April 2021 I made my first commit to the monorepo behind CARTO’s cloud-native platform. It was PR number 9, a docker-compose. Five years later I’ve looked back with some calm and found around 450 commits, around 447 pull requests, and a presence in virtually every service in the repository.

The numbers aren’t the interesting part. What’s interesting is that, going through that history, a thread shows up that I hadn’t fully identified myself: I’ve spent half a decade connecting the platform to other people’s data warehouses. Six different providers — BigQuery, Snowflake, Redshift, Databricks, Oracle and PostgreSQL — each with its own credential model, its pooling, its timeouts and its error messages.

The problem: httpfs ignores your environment variables

If you work with DuckDB and the httpfs extension to read remote Parquet files, CSVs from S3, or any HTTP resource, you probably assume that the HTTP_PROXY and HTTPS_PROXY environment variables work just like every other tool. Curl respects them. wget respects them. Python requests respects them. Node.js respects them.

DuckDB does not.

I ran into this while working in a corporate environment with a mandatory proxy. I had a script reading Parquet files from Google Cloud Storage using httpfs, and it simply would not work. No clear error, no descriptive timeout, just silence. Meanwhile, a curl to the same resource with the same environment variables returned data without issue.

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.

Every query starts with a plan. Every slow query probably starts with a bad one. And more often than not, the statistics are to blame. But how does it really work?

PostgreSQL doesn’t run the query to find out — it estimates the cost. It reads pre-computed data from pg_class and pg_statistic and does the maths to figure out the cheapest path to your data.

In the ideal scenario, the numbers read are accurate, and you get the plan you expect. But when they’re stale, the situation gets out of control. The planner estimates 500 rows, plans a nested loop, and hits 25,000. What seemed like an optimal plan turns into a cascading failure.