PostgreSQL 18 as a managed Data Service, not just a systemd unit
Sysaro connects PostgreSQL 18 inventory with databases, access, backup/restore and health. Privileged work is exposed as typed Agent operations rather than a generic SQL or root shell.
How the service fits into Sysaro
What Sysaro already manages
Discovery and version policy do not treat an arbitrary PostgreSQL major as PostgreSQL 18.
Database and access operations live in the dedicated Data Services surface while service lifecycle remains tied to Agent jobs and the audit trail.
Backup and restore are managed workflows with observable state rather than an arbitrary pg_dump command exposed to the browser.
Management boundary
Sysaro does not equate PostgreSQL detection with automatic database tuning. Structured postgresql.conf tuning schemas remain a separate roadmap item.
Local operations use the postgres OS identity where required and do not expose a generic root shell.
Privileges on existing objects and future default privileges are distinct; the UI does not imply that future tables are covered unless explicitly configured.
Where this fits
PHP applications using nginx, PHP-FPM 8.5 and PostgreSQL 18.
Temporal workflow deployments where PostgreSQL is a persistence dependency.
Operations where reproducible backup/restore and auditability matter more than ad-hoc SSH administration.
What this page does not claim
Detection, lifecycle or a typed subset is not described as complete management of every upstream capability. The canonical current scope is also published in service-evidence.json and the 18-service catalog.