Cuándo implementar o actualizar a una nueva versión principal de PostgreSQL

October 20, 2020

Con el lanzamiento de PostgreSQL 13, realizado el día de ayer, quizás sea un buen momento para hablar de cuándo y cómo debería implementarse la nueva versión de la base de datos. A menudo escuchamos preguntas como "¿Cuándo debería actualizar?" y "¿Debería cambiar mi plan de nueva implementación a la nueva versión?"

Lo primero que hay que considerar es esto: no debería implementar ningún software que no haya probado. Así que, a menos que haya evaluado exhaustivamente la aplicación con las versiones Beta y Release Candidate, no debería implementarla de inmediato. En el caso de un gran número de implementaciones, no existe una buena razón para actualizar, ya que funcionan muy bien y no requieren ninguna de las características de la nueva versión. A menudo se observan implementaciones exitosas en las que, durante años, no se realizan actualizaciones. Necesitan únicamente las versiones de corrección de errores que la comunidad PostgreSQL produce regularmente, que son actualizaciones sencillas, y que requieren mucho menos pruebas y validación que una nueva versión principal..

Cuando se lanza una nueva versión, lo primero que debería hacerse es consultar las notas de la versión. Revisar especialmente, la sección Migración que siempre aparece en el documento. Debería observar si existe algo que pueda perjudicarle. En muchos casos no lo habrá, pero debería comprobarlo en caso de que sí exista. Luego observe las características. Si encuentra algo que necesita, entonces debería planear una implementación. Eso significa que, de ser necesario, debería realizar una serie completa de actualizaciones de la aplicación y luego pruebas de integración. Sólo entonces debería considerar la posibilidad de instalar la nueva versión.

Aproximadamente cada tres meses, la comunidad PostgreSQL produce versiones de corrección de errores para todas las series de versiones soportadas (más o menos cualquier versión principal con menos de cinco años de vida). En muchos casos, si usted empieza su planificación tras el lanzamiento de una versión principal, no estará listo para su implementación hasta que aparezca la primera versión de corrección de errores de la misma. Si usted, al igual que muchas personas y organizaciones, prefiere no instalar las versiones .0, entonces puede planear una fecha razonable de implementación de, digamos, cuatro meses después de su lanzamiento. PostgreSQL ha resultado ser generalmente mucho más estable y fiable que otros softwares, por lo que creo que, en comparación con otros productos, existen más razones para confiar en sus versiones .0.

Existirán casos en los que realmente querrá instalar la nueva versión lo antes posible. Aunque esto puede deberse a alguna característica innovadora, a menudo, en el caso de las implementaciones existentes, se debe a mejoras en el rendimiento o a la eliminación de alguna limitación que resultaba molesta. En esos casos es razonable implementar la nueva versión lo antes posible. Pero, bajo ningún concepto deberían omitirse las pruebas de integración mencionadas anteriormente. “La prisa es mala consejera” es un buen lema para la gestión del software.

Si usted es un entusiasta de la adopción temprana, entonces, a medida que la comunidad PostgreSQL se acerca a una nueva versión, esté pendiente de las versiones Beta. Suelen aparecer a mediados de año. Este año la versión Beta 1 estuvo disponible a finales de mayo, mientras que la fecha habitual de lanzamiento de la versión definitiva es alrededor de septiembre. Puede empezar a evaluar estas versiones. Por supuesto, no deberían implementarse en producción, pero si no identifica ningún problema durante las pruebas, estará listo para implementar la versión final poco después de su lanzamiento. Esta es también una muy buena manera de ayudar a la comunidad, puesto que nos ayuda a identificar los errores antes del lanzamiento de la versión definitiva, y a validar las versiones.

Share this

Relevant Blogs

Random Data

This post continues from my report on Random Numbers. I have begun working on a random data generator so I want to run some tests to see whether different random...
December 03, 2020

More Blogs

Full-text search since PostgreSQL 8.3

Welcome to the third – and last – part of this blog series, exploring how the PostgreSQL performance evolved over the years. The first part looked at OLTP workloads, represented...
November 05, 2020

Números aleatorios

He estado trabajando gradualmente en el desarrollo desde cero de herramientas para probar el rendimiento de los sistemas de bases de datos de código abierto. Uno de los componentes de...
November 04, 2020