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.
