Release Policy

EDB practices Agile's Scrum methodology across most of its products, with the database as a current exception given our direct contributions and interdependencies on the PostgreSQL release timing. Major releases of the database server are once per year, minor releases are once per quarter, where EDB Postgres Advanced Server intends to follow PostgreSQL releases as closely as possible in time; typically this is 4-6 weeks for major and 1-2 weeks for minor releases.

EDB releases minor version updates on a 60 and 90-day release cycle, dependent on the product; each minor version is comprised of a number of EDB internal development sprints constituting this external release. EDB executes diligence and agility for specific customer requirements based on several factors, principally: the impact as observed by the customer, the type of work (defect vs enhancement request), and in the case of a problem, the underlying effort associated to full code remediation. As an example - if an issue is a "0-day" which is a consequence of the product architecture, that may impact our ability to address the problem in a patch or hotfix. If it is a defect resulting from code introduction which can be remediated in a short period of time, EDB does its best to address that need.

Additionally, all of these efforts are also guarded by our SLA goals - if we cannot provide a patch in the time which correlates to the severity, which is often the case as you need to test a given fix before releasing it to customer-imperative environments, our effort becomes focused on providing a workaround which allows restoration of the compromised functionality.

EDB ensures proper understanding of the customer scenario by allowing for both the severity of the event to be understood (as defined in our Terms and Conditions) as well as the priority to the customer. As an example, if a customer experiences an issue in a development environment using a feature in a specific way, we will ensure we do our best to provide means to remediate, despite the fact that it may not be a production environment. The priority can be set by the customer in the case submission itself.

EDB then provides an escalation process within its Support documentation provided to the customer during on-boarding, which contains contact details for all key points of responsibility in the Support Services practice. EDB also encourages discussion with sales resources and a Technical Account Manager where applicable, particularly for feature requests which may require reallocation of resource capacity.

As it pertains solely to vulnerabilities (IE, CVE/CVSS "critical" events):

  1. If it is a vulnerability in PostgreSQL itself (rather than EDB Postgres Advanced Server's version thereof), we release the patch or fix to customers at the same time as the PostgreSQL community will. Any workarounds, if available, would be made available in advance during the announcement of the vulnerability if a fix is not yet available, and this too would be organized with the PostgreSQL community. Generally, the vulnerability is exposed and remediated in concert.
  2. If the vulnerability is EDB Postgres Advanced Server or EDB Postgres Tool specific, we release the patch or fix to customers at its earliest availability. Any workarounds, if available, would be made available in advance during the announcement of the vulnerability if a fix is not yet available.

As to guidance on testing releases prior to production deployment:

  1. Where it pertains to EDB Postgres Advanced Server and PostgreSQL, minor releases are focused solely on defect resolution.  As we aren't introducing features or functionality, it is the safest form of incremental release.  Most of our customers elect to apply their own version/change management methodology, and these releases are generally the lowest risk.
  2. Where it pertains to EDB Postgres Tools (such as Postgres Enterprise Manager, Failover Manager, Replication Server, or Backup and Recovery Tool) we recommend full testing; minor versions may introduce different functionality or behavior, and should be treated accordingly for testing purposes.