Привет, в классических Postgres (операторы не исключение) миграции и хелмы/плейбуки — наше всё, и кажется, ничего лучше не придумать. В Neon дев и стейдж фактически унифицированы, т.к. это stateless Compute, который поднимается из одних образов, а тюнинг доступных параметров осуществляется при работе с управлялкой кластера. Тут важно заметить, что многие задачи решаются самим Neon в рамках автоматизированных сценариев. Например, так как Neon сам занимается upscale и downscale задачами, помимо добавления непосредственно ресурсов к экземплярам он апдейтит конфиги (при добавлении новых ядер он автоматически апдейтит значения max_parallel_workers и т.д.).
Миграции в Neon также отличаются. За счёт ветвления базы можно создавать изолированные копии прода, на которые можно накатить и предварительно прогнать изменения (например, создание и удаление тестового стенда в рамках CI/CD). Но по итогу нам необходимо либо переключить прод на релизную ветвь, либо накатить миграцию на prod-ветвь.
Привет, в классических Postgres (операторы не исключение) миграции и хелмы/плейбуки — наше всё, и кажется, ничего лучше не придумать. В Neon дев и стейдж фактически унифицированы, т.к. это stateless Compute, который поднимается из одних образов, а тюнинг доступных параметров осуществляется при работе с управлялкой кластера. Тут важно заметить, что многие задачи решаются самим Neon в рамках автоматизированных сценариев. Например, так как Neon сам занимается upscale и downscale задачами, помимо добавления непосредственно ресурсов к экземплярам он апдейтит конфиги (при добавлении новых ядер он автоматически апдейтит значения max_parallel_workers и т.д.).
Миграции в Neon также отличаются. За счёт ветвления базы можно создавать изолированные копии прода, на которые можно накатить и предварительно прогнать изменения (например, создание и удаление тестового стенда в рамках CI/CD). Но по итогу нам необходимо либо переключить прод на релизную ветвь, либо накатить миграцию на prod-ветвь.