Los cuatro jinetes que derriban miles de bases de datos Postgres

Postgres es una base de datos muy utilizada, pero arrastra varios problemas recurrentes que provocan caídas en producción, sobre todo en equipos sin un administrador de bases de datos dedicado. El desarrollador detrás de pgrust, una reescritura del motor en Rust, identifica cuatro causas principales. La primera es el sistema VACUUM y el wraparound de identificadores de transacción: al borrar filas, Postgres solo las marca como eliminadas y deja a un proceso en segundo plano la tarea de liberarlas. Si VACUUM se queda atrás, puede ralentizar las consultas al consumir E/S y, en el caso extremo del wraparound de 32 bits, obligar a apagar la base de datos para evitar corrupción. La segunda son los límites de conexión, ligados al modelo basado en procesos, que encarece el paralelismo tanto entre consultas como dentro de una misma consulta; herramientas como PgBouncer mitigan el problema sin resolverlo. La tercera causa son los planes de consulta defectuosos: cuando el optimizador elige un mal algoritmo, una consulta puede pasar de 10 milisegundos a 10 minutos, y Postgres ofrece poco control al usuario, a diferencia de MySQL, que admite hints. Por último, el uso de JSON, muy cómodo para datos no estructurados, impide a Postgres recoger estadísticas fiables sobre los datos y degrada el rendimiento. pgrust plantea soluciones en cada frente: identificadores de transacción de 64 bits, arquitectura basada en hilos aprovechando la seguridad de Rust, un optimizador adaptativo capaz de detectar regresiones, y un mejor tratamiento de JSON.