Curious how you're planning to handle Postgres versions going forward - will v16 be a hard requirement for new OSS deployments? What's your strategy for managing existing deployments on older versions?
Thank you! We generally try to stay in line with the supported versions of the technologies we use: Postgres, NodeJS, Redis, etc.
For Postgres in particular, part of the motivation for doing this upgrade when we did was (besides the very meaningful performance improvements) is that Postgres 12 will no longer be supported by Aurora after February 25, 2025.[0]
Officially, Medplum v3 (our current newest version) requires Postgres 12+. We're just about to release v4 which will support 13-17 based on the support dates published by Postgres[1]. We're still finalizing more formal documentation on our versioning strategy going forward.
Comments
Hey - great writeup!
Curious how you're planning to handle Postgres versions going forward - will v16 be a hard requirement for new OSS deployments? What's your strategy for managing existing deployments on older versions?
Thank you! We generally try to stay in line with the supported versions of the technologies we use: Postgres, NodeJS, Redis, etc.
For Postgres in particular, part of the motivation for doing this upgrade when we did was (besides the very meaningful performance improvements) is that Postgres 12 will no longer be supported by Aurora after February 25, 2025.[0]
Officially, Medplum v3 (our current newest version) requires Postgres 12+. We're just about to release v4 which will support 13-17 based on the support dates published by Postgres[1]. We're still finalizing more formal documentation on our versioning strategy going forward.
[0]. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQ...
[1]. https://www.postgresql.org/support/versioning/