MySQL, MariaDB and PostgreSQL without database guesswork
See how SHM manages MySQL, MariaDB and PostgreSQL databases, users, grants, activity, phpMyAdmin and pgAdmin safely from one account workspace.
Create databases, manage users and grants, inspect account-owned activity, and open phpMyAdmin or pgAdmin without losing the account boundary.
Working with the engines
One workflow, two engines
Hosting accounts rarely stay simple forever. A familiar PHP application may use MariaDB today, while a newer service arrives with PostgreSQL tomorrow. SHM keeps both in the same database workspace while preserving the rules specific to each engine. The controls follow a common rhythm - create the database, create or attach a user, define access, and verify the result - while each engine keeps the rules that make it reliable. For MySQL-compatible workloads, SHM supports MySQL and MariaDB database and user management. PostgreSQL receives its own native workflow, including PostgreSQL-safe identifiers and privilege handling. The panel validates identifiers and access requests before they reach the database service.
Make access explicit
A database is useful only when the right application can reach it. SHM can create a database, create a user, attach that user, and manage permissions from the account boundary. MySQL and MariaDB users can receive selected grants or full access to the intended database, while allowed hosts remain visible as part of the managed configuration.
PostgreSQL follows the same practical goal with engine-specific privilege templates. Database users, allowed remote addresses, and grants are managed deliberately. Root and PostgreSQL superuser access are not handed to account users, because convenience should not turn into a server-wide permission problem.
Visibility without overreach
Activity, scoped to the account
When a site slows down, database activity should be verified before it is treated as the cause. SHM provides process views for supported database engines so an account can inspect activity associated with its own databases and users. MySQL activity can be reviewed and an owned process can be terminated when it is genuinely stuck. PostgreSQL includes corresponding account-scoped activity and termination controls.
The important word is owned. These views are not a window into another customer's workload, and they are not a shortcut to global database administration. Root has broader operational views; an account sees the part it is responsible for.
Familiar tools, safer entry
If phpMyAdmin or pgAdmin is installed by the server administrator, SHM provides a direct account entry into the appropriate tool. The handoff uses short-lived, account-scoped access rather than asking users to share a server administration login. pgAdmin is prepared with the databases available to that account, and phpMyAdmin follows the same principle for MySQL-compatible data.
These tools are optional services, not hidden dependencies. The database manager still handles the everyday lifecycle without them. When they are enabled, they are an additional workspace for SQL, browsing, imports, and exports - not a reason to widen database privileges.
Operations that have to scale
Routine operations at real-world sizes
Database administration should make routine jobs predictable and repeatable. Names are validated, passwords are handled as credentials, grants are visible, and destructive actions are separated from ordinary edits. SHM also configures the database toolchain so supported dump and import operations use the same practical packet limits.
The result is not a new database language. It is a safer operating layer around the databases applications already use: enough control for real work, enough visibility for troubleshooting, and clear boundaries when an operation requires server-administrator authority.