We use it locally with minikube and kind, and this is pretty ephemeral.

Maybe we need to look into how storage class config can be supported?

Otherwise for the cloud is there a difference? You want to use node local storage? I think this gets our attention once we have i3 and i3en pools of worker nodes to properly support more io heavy scenario.

No, I mean really ephemeral.

Node-local storage works now using hostPath and the hostPath Dynamic Provisioner. Someday in the future Kubernetes will support dynamic provisioning of LocalPV, and that'll get even simpler.

This came up because I wanted to use the postgres-operator for a training, but the learning environment doesn't support real PVs. The same situation would apply if you wanted to run automated testing on a real cluster instead of using Kind, which you would want to do if you wanted to do automated failover tests through node restart.

If it's a serious PITA, then never mind, but I'd think that it would be possible to offer a keyword that would just create emptydir()s, like "emptydir" or "ephemeral" in place of the StorageClass.

For that matter, outside of the test scenario, I've had clients who used Postgres as their caching layer, so there's also production reasons to support having emptydir nodes.

It is good to have the problem and the use cases outlined and then we or someone who wants to work on this can implement this. Right now we don't have this need on our mind.

I had not judged the implementation effort at all.

Thanks for the hints on the local storage, one needs to keep up with all the changes.

In case I write this ... is the approach of using a keyword in place of StorageClass the right approach, or do we want to add an additional field (ephemeral, defaulting to False)?

If I understand this right we would if enabled for a particular cluster have the pgdata volume not via volume claim template, but explicitly set to emptyDir volume.

volumes:
  - name: pgdata
    emptyDir: {}

So if done right the operator config would have something like:

allow_ephemeral_volumes: False(default)

And the Postgres CRD would allow for:

useEphemeralVolume: False(default)

And if bold we also have

ephemeralVolumeType: "disk" (default) or "memory"

That should be fairly straight forward to do in the generate statefulset.

(edit for proper camel case in config map and snake in crd)

Risk
How should we deal with migrations? How to deal with ephemeral to non ephemeral migration?

@jberkus - Please confirm if you found the solution for same :)

it's been some time, but just to say there may be users like me who are also interested in this feature

It would be great if you'll develop an emptyDir

Nope. I'm not supporting postgres-operator in production anymore, so I never got around to writing the code for this. Someone else should take it on!