+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. > > > >
