Databases on Antonio Cortés (DrZippie)

Postgres sobre QUIC: el cuello de botella que no está en la base de datos

Wed, 30 Sep 2026 00:00:00 +0000

Cualquiera que haya llevado Postgres a producción con algo de carga ha pasado por lo mismo: pones PgBouncer o PgCat delante, configuras el pooling por transacción, limitas las conexiones reales al servidor para que no se quede sin memoria… y las consultas siguen yendo lentas en los picos, con la base de datos casi sin hacer nada.

El artículo Postgres with QUIC pone el foco en un sitio donde casi nunca miramos: el tramo entre la aplicación y el pooler. Y para arreglarlo prueban algo que no había visto antes: hablar el protocolo de Postgres sobre QUIC en lugar de TCP.

AWS compra DuckLabs: qué cambia y qué no para quienes usamos DuckDB

Sat, 29 Aug 2026 00:00:00 +0000

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.

Cinco años conectando data warehouses: lo que he aprendido

Sat, 29 Aug 2026 00:00:00 +0000

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.

DuckDB y httpfs detrás de un proxy: el secreto que nadie te cuenta

Mon, 02 Mar 2026 00:00:00 +0000

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.

Cómo PostgreSQL estima tus consultas (y por qué a veces se equivoca)

Fri, 27 Feb 2026 00:00:00 +0000

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.