The Kubernetes getting-started guide still deploys Keycloak as a StatefulSet. Now that user sessions
are persisted in the database by default in recent releases, I'm trying to understand whether that is
still technically necessary, or whether a plain Deployment would be equivalent. I'd like a sanity
check before we switch.

My reasoning - a StatefulSet provides three guarantees, and none seem to apply to a DB-backed
Keycloak:

1. Stable per-pod storage (volumeClaimTemplates) - Keycloak writes nothing to local disk, so there is
   nothing to persist per pod.
2. Stable network identity (pod-0, pod-1, …) - cluster discovery uses DNS_PING (headless service) or
   JDBC_PING (DB), i.e. membership is label-/DB-based, not tied to the pod ordinal or hostname. A
   Deployment's pods are discovered the same way.
3. Ordered, one-at-a-time rollout - the only remaining difference, but a Deployment with RollingUpdate
   (maxUnavailable: 0) plus a PodDisruptionBudget seems to cover availability just as well, arguably
   better (no capacity dip during rollout).

The part I want to double-check: persistent sessions remove the "losing a pod loses user sessions"
concern, but the embedded Infinispan cluster is still needed for authenticationSessions, actionTokens,
loginFailures and cache invalidation. However, that requires clustering, not stable node identity -
so it doesn't seem to be an argument for a StatefulSet either.

Questions:

• Is there any remaining technical reason to prefer a StatefulSet over a Deployment for a Keycloak
  with no local storage and an external DB?
• Are DNS_PING / JDBC_PING discovery and rolling updates fully supported with a Deployment?
• If a Deployment is fine, is the StatefulSet in the getting-started guide mainly historical - and
  would a Deployment-based example be welcome?

Have I overlooked anything? We plan to run ≥2 replicas behind an HPA" - that reframes it from a theoretical question to a real autoscaling scenario, where StatefulSet ordering is actively awkward.

Environment: Keycloak 26.x, GKE, external database, embedded Infinispan.