Create databases, restricted users and website bindings

Select a real engine and account

Open Databases → New database with an active eligible account. The capability response determines engines. MariaDB is separate from Panel's private PostgreSQL metadata. A customer PostgreSQL option is usable only when the advertised separate instance is supported; never target the Panel database. Names match lowercase letters followed by lowercase letters, digits or underscores, up to 48 characters.

Complete each durable step

1. Create the database with account_id, engine and name; wait for its operation to succeed.
2. Create a restricted user with name, private password, database-local grants and supported limits; wait for success.
3. Optionally choose an active same-account website and create a binding with user_id, website_id and the privately supplied user password.
4. Verify the connection result and the application's real connection. A submitted first step does not mean the later user or binding exists.

Database/user passwords must be 16–1024 UTF-8 bytes in this interface. Keep them in private application configuration; operation history does not reveal them. A binding is not proof of application-level migrations or a fully configured WordPress site.

Grant reference

MariaDB exposes alter, create, delete, index, insert, select, update; defaults are delete, insert, select, update. PostgreSQL exposes connect, create, delete, execute, insert, references, select, temporary, trigger, truncate, update, usage; defaults are connect, create, delete, insert, select, update, usage. Choose only what the application needs. These are database-local grants, not server administration or access to another account.

Supported user-resource limits are advertised per engine. The UI offers maximum concurrent connections from 0–10000 and statement time from 0–3600000 milliseconds only when supported. Zero is no requested user cap. Other limit keys are sent as zero rather than implying hourly enforcement.

Maintain the resource

Current user detail supports grant changes, supported limits, password rotation and deletion with revision checks. Rotate credentials deliberately and update dependent applications privately. Website bindings can be inspected and removed separately. Database suspension/reactivation/deletion is a durable lifecycle flow; deletion requires the actual impact preview and confirmation.

Verify and troubleshoot

Check the database, user and binding independently and test with the least-privileged application user. On failed intermediate steps, inspect the operation before recreating resources. A missing engine is not fixed by selecting an unsupported string. Dedicated repair/optimization/process-list interfaces and phpMyAdmin are not implemented. Schema exports do not necessarily reconstruct users, grants or application secrets; include those in a separately reviewed recovery plan.