[Fix] TimescaleDB connection exhaustion by model monitoring

[alxtkr77]

📝 Description

CE ships TimescaleDB with max_connections=25 — the value timescaledb-tune derives
at first boot for a 1Gi pod. Model monitoring holds ~21 standing connections per
monitored project (controller workers, writer/stream storey targets), so a single
busy project exhausts the server and queries fail with
FATAL: sorry, too many clients already.

The limit is now pinned explicitly via a server argument. This is deliberate:
timescaledb-tune only runs on an empty data directory, and the PVC is kept across
upgrades (helm.sh/resource-policy: keep) — a tune-side or memory-driven change
would never reach existing installs, while a -c argument overrides
postgresql.conf on every pod start.

---

🛠️ Changes Made

• New timescaledb.maxConnections value (default 100, ~4 concurrent monitored projects)
• Pass postgres -c max_connections=... as container args in the TimescaleDB StatefulSet
• Raise TimescaleDB memory limit 1Gi → 2Gi (~3MB per open backend; keeps fresh-install
  headroom after timescaledb-tune sizes shared_buffers for the larger pod)
• Chart version 0.12.0-rc.5 → 0.12.0-rc.6

---

✅ Checklist

• I have tested the changes in this PR
• I confirmed whether my changes require a change in documentation and if so, I created another PR in MLRun for the relevant documentation.
• I confirmed whether my changes require a changes in QA tests, for example: credentials changes, resources naming change and if so, I updated the relevant Jira ticket for QA.
• I increased the Chart version in charts/mlrun-ce/Chart.yaml.
• I confirmed that the installation works both on a local Docker Desktop environment and on a real cluster when using the required prerequisites.
  • If installation issues were found, I updated the relevant Jira ticket with the issue and steps to reproduce, or updated the prerequisites documentation if the issue is related to missing or outdated prerequisites.
• If needed, update https://github.com/mlrun/ce/blob/development/charts/mlrun-ce/README.md with the relevant installation instructions and version Matrix.
• If needed, update the following values files for multi namespace support:
  • Admin values
  • User values Node Port
  • User values ClusterIP

---

🧪 Testing

• helm template render verified: args: [postgres, -c, max_connections=100] on the
  TimescaleDB container
• Image config (timescale/timescaledb-ha:pg17.7-ts2.24.0) verified:
  Entrypoint: docker-entrypoint.sh, Cmd: [postgres] — the explicit args preserve the
  default startup path
• Cluster install pending

Note: the multi-namespace values files need no sync — they only override
timescaledb.enabled / service type.

---

🔗 References

• Ticket link: https://ecliptos.atlassian.net/browse/ML-12857

---

🚨 Breaking Changes?

• Yes (explain below)
• No

---

🔍️ Additional Notes

Existing installs pick up the new limit on the next pod restart (rollout on upgrade).
SDK-side hardening (shared pool per DSN, min_size=0) is a separate follow-up in
mlrun/mlrun — it reduces mlrun's connection footprint but would not have prevented
this failure mode on its own.

[royischoss]

LGTM