Understanding the v1alpha1 hard CRD limits (single database, single shard): roadmap & recommended patterns

[tz-torchai]

Hi team, thanks for Multigres and for how cleanly the operator is put together.

I'm evaluating multigres-operator for a GitOps-managed IPV6-only cluster, and I'd like to understand two v1alpha1 constraints and their trajectory:

1. One logical database per cluster, must be named postgres: api/v1alpha1/multigrescluster_types.go:90-91:

 // +kubebuilder:validation:MaxItems=1
 // +kubebuilder:validation:XValidation:rule="self.all(db, db.name == 'postgres' && db.default == true)",
 //   message="in v1alpha1, only the single system database named 'postgres' (marked default: true) is supported"
 Databases []DatabaseConfig `json:"databases,omitempty"`

2. Shard name locked to 0-inf: multigrescluster_types.go:360-362:

// +kubebuilder:validation:XValidation:rule="self == '0-inf'",message="shardName must be strictly equal to '0-inf' in this version"
 Name ShardName `json:"name"`

I understand the project is pre-production and these are deliberate guardrails (the multi-shard scaffolding, e.g. Shards MaxItems=32, per-shard pgBackRest repos, is already there). My questions:

• Are multiple logical databases per cluster and multi-shard on the roadmap as independent milestones, and if so, roughly in what order? Some workloads we'd host need more than one logical database, which is a separate concern from horizontal sharding.
• Given today's one-database-per-cluster rule, is the recommended pattern one MultigresCluster per application database, or is a shared multi-database cluster the intended end state once the limit lifts?

These two limits are the specific gating factors for adopting Multigres in our fleet, so I'm keen to understand whether they're on the near-term roadmap. I couldn't find an existing issue tracking them, would you be open to a tracking issue (happy to open one). We'd gladly contribute evaluation feedback: HA/failover, IPv6-only bind behavior etc.