PostgreSQL: Se acabó VACUUM, se acabó el bloat

• PostgreSQL es un potente sistema de base de datos de código abierto, conocido por su solidez y flexibilidad.
• Uno de los desafíos de PostgreSQL es el proceso VACUUM, que consume recursos y se usa para limpiar datos antiguos y liberar espacio.
• OrioleDB es un nuevo motor para PostgreSQL diseñado para eliminar la necesidad de VACUUM y evitar la inflación de las tablas.
• OrioleDB logra esto mediante la implementación de registros undo a nivel de fila y de bloque, junto con la fusión automática de páginas.
• Estas funciones crean un sistema que requiere menos intervención manual, consume menos recursos y no es vulnerable a la inflación de tablas.
• Según los resultados de benchmarks, OrioleDB ofrece mayor TPS, menor carga de CPU por transacción, menos IOPS por transacción y un rendimiento sin inflación de tablas ni índices en comparación con PostgreSQL tradicional.
• OrioleDB ofrece una solución interesante a uno de los desafíos más antiguos de PostgreSQL, con la promesa de mejorar la eficiencia y reducir la carga de mantenimiento.
• Los usuarios pueden probar OrioleDB desde hoy y sumarse a la revolución para una experiencia de PostgreSQL más simple y eficiente. Visita GitHub para probar OrioleDB.

[GN⁺]

Opiniones de Hacker News

• El proyecto OrioleDB, un nuevo motor de almacenamiento para PostgreSQL, ha recibido críticas por hacer un fork de un proyecto de código abierto e introducir cambios importantes sin que quede claro su plan de mantenimiento.
• También se critica que el README principal de OrioleDB en GitHub suena demasiado corporativo y no ofrece suficiente información sobre el proyecto.
• Hay confusión sobre por qué OrioleDB se promociona como una base de datos completamente nueva en lugar de contribuir mejoras al propio PostgreSQL.
• Los benchmarks de rendimiento de OrioleDB muestran una menor sobrecarga de CPU por transacción en comparación con PostgreSQL, pero existe preocupación por su uso constantemente alto de CPU.
• Si OrioleDB es superior al motor interno de PostgreSQL, surge la pregunta de por qué los grandes proveedores de nube no lo han adoptado; también se especula que, si lo hicieran, PostgreSQL podría reemplazar su motor predeterminado.
• Hay curiosidad sobre la compatibilidad de OrioleDB con otras extensiones como TimescaleDB.
• Se mencionó un blog titulado "10 cosas que Richard Branson odia de PostgreSQL", pero luego se aclaró que el autor en realidad es Rick Branson.
• Se discute el papel de vacuum en PostgreSQL y se reconoce que hace más que simplemente eliminar tuplas muertas.
• Se solicita documentación sobre el "parche de escalabilidad" usado en OrioleDB y hay confusión sobre cómo se integra con PostgreSQL core.
• Existe confusión sobre el término "objeto-relacional" y se pide una explicación de su significado.