+1 on the Kustomize direction and keeping Postgres out of the helm-chart by default.
A simple dev postgres statefulset (disabled by default) makes sense for quick testing and CI. We should document the Zalando operator as a recommended path for production, but not ship it. If we opt for Kustomize, we should provide a clear example overlay illustrating how to add the Zalando operator. That lowers the barrier and shows the pattern for other extensions. *Ankit Chaurasia* On Mon, Dec 8, 2025 at 10:48 AM Amogh Desai <[email protected]> wrote: > +1 on simplifying our helm charts and detailed documentation on how to > spin up and use Kustomize too. > > As Jed and Jens already mention, I am not in favour of *integrating *a > postgres > operator as a piece of Airflow out-of-box. This will only lead down a dirty > path in > the future where we will have to start caring about DB problems irrelevant > to > Airflow. > > We could spin up a statefulset as Jed mentioned for people who want to spin > up > a postgres for dev purposes using helm charts. It should be fairly simple > to do that. > > Thanks & Regards, > Amogh Desai > > > On Fri, Dec 5, 2025 at 5:37 AM Jarek Potiuk <[email protected]> wrote: > > > +1 on all written by Jed and Jens. Great proposal. > > > > On Thu, Dec 4, 2025 at 8:49 PM Jens Scheffler <[email protected]> > wrote: > > > > > +1 to all Jed said - and as I said during devcall. > > > > > > We can point to the Postgres operator as a good example and drop some > > > notes as an example how to make it running such that a low entry > barrier > > > is there. But DB operations is complex, you need backups, disaster > > > recovery, HA, need to monitor and tune performance, many different > > > storage backends. Might all be good and Zalando might really have a > good > > > job but still it is easily getting into a direction where it is > expected > > > we drive also support. > > > > > > We might and should provide a minimal example that we also use for our > > > CI (can be the opertor or a simple 10-line YAML to deploy a simple > > > postgres container just for testing. But the easiest is like Jed also > > > mentioned during the call to just call the following CLI: > > > > > > |kubectl run postgres --image=postgres > > > --env="POSTGRES_PASSWORD=yourpassword"--port=5432| > > > > > > Fpr Kustomize I am also OK with the assumptions: > > > > > > * We provide a space where documented examples can land which can be > > > easily contributed by users such that people can easily "shop" for > > > additional features > > > * For all stuff we strip-out of the chart we should move an example > as > > > replacement > > > > > > That also means - like Jarek referenced - we should reduce the PR to > > > remove postgres to really only remove postgres from the chart but not > > > adding sqlite. Sqlite is cool for `airflow standalone` but I am afraid > > > about the complexity adding this with shared storage to the chart. > > > > > > Jens > > > > > > On 12/4/25 17:12, Jed Cunningham wrote: > > > > Big +1 on significantly simplifying our chart and documenting how to > > use > > > > Kustomize. I've been shopping that idea around for a while now and > have > > > > received nearly universal thumbs up on the idea. It's very similar to > > how > > > > we moved from exposing "everything in the pod" in Airflow config to > the > > > > pod_template_file back in 1.10.something - same high level problem. I > > > think > > > > this is the right direction for the chart and it will help a lot to > > make > > > it > > > > more maintainable. > > > > > > > > However, I'm not sold on integrating the postgres operator and trying > > to > > > > offer a "production" db out of the box. There is just too much that > > goes > > > > into it. I'd be very happy to, however, document how it can be done > and > > > > possibly even test that it works. But I do not think we should stand > up > > > > that piece of the puzzle for people. Alternatively, what do you think > > > about > > > > having a very simple statefulset/service to stand up a "dev" db - we > > can > > > > even move the config to something like `devPostgres` or something and > > > leave > > > > it disabled by default. Then we maintain the ease of "single command > to > > > > stand up", we can use it for the bulk of our tests, etc. Of course, > > folks > > > > could choose to kustomize away and use it, but no one could argue > they > > > > thought it was a fully supported production level thing then and they > > are > > > > on their own. > > > > > > >
