Managing databases for UK client websites

A database stores structured information used by an application, such as content, customer records or settings. Managing client databases means protecting that data, keeping application access correct and being able to recover after an error or migration. A working homepage is not enough evidence that the data service is healthy.

Begin with the application’s supported database engine and the actual hosting plan. A panel listing SQL databases does not prove that PostgreSQL, every NoSQL service or arbitrary server-level configuration is included. Verify the workload before deployment.

Relational and non-relational choices

MySQL, MariaDB and PostgreSQL are relational systems with their own capabilities and compatibility requirements. An application’s documented support should guide the engine and version choice. They are not drop-in substitutes for every project.

Non-relational systems use other data models, such as documents or key-value structures. They can suit particular workloads, but they are not automatically a more scalable answer or a standard feature of every reseller account. Choose according to the application and operating support available.

1. Plan ownership and structure

Record which client and application owns each database, its purpose and the authorised administrators. For custom development, define the data model and relationships deliberately rather than accumulating unreviewed tables.

Keep staging and production identifiable. Test data and live personal information need appropriate handling. A database name should help an operator select the right service, but the full credential belongs in a controlled secret store.

2. Verify the supported engine and limits

Check the host’s available engine, version, database count, storage accounting and access model. Determine whether a required extension or server setting is available to the account or needs another service.

The reviewed telaHosting Starter cPanel catalogue lists two SQL databases. That is an allocation statement, not a promise that every engine or a database of any size is supported. Match it to the actual application before choosing the plan.

3. Make backups appropriate to changing data

Choose frequency and retention according to how much recent data the application can tolerate losing. A frequently changing shop and a rarely edited information site have different recovery needs.

Keep backups protected and verify restoration. For applications such as WordPress, database data and relevant files need a coherent recovery point. A successful file copy alone does not recover orders, content or settings held in the database.

4. Secure the application’s database use

Use a separate application user with the permissions required for its own database. Protect credentials and rotate them through a controlled process. Restrict remote exposure to what the documented architecture needs.

Application code should use parameterised queries or the framework’s appropriate safe access method. A panel interface and strong password do not prevent SQL injection in vulnerable code. Keep the application and supported components maintained.

5. Investigate query performance

Collect evidence about slow operations and use the engine’s tools, such as EXPLAIN where appropriate, to understand query plans. Review indexing, data access patterns and unnecessary work before assuming the only answer is more hosting capacity.

Measure comparable application behaviour after a change. An index can help some queries and impose costs on writes or storage. Test with representative data rather than treating every suggested index as an automatic improvement.

6. Monitor capacity and operational health

Track database growth, connection errors and relevant resource indicators available from the application or provider. Keep maintenance tasks and their outcomes in the service record.

A shared-hosting account may not expose all engine-level metrics. Escalate with the query, timestamp, workload and sanitised evidence rather than attempting server-wide configuration outside your role. Keep personal data and secrets out of public support examples.

7. Plan growth and migrations

Estimate foreseeable data and workload changes and identify the next suitable architecture. A growing database may require optimisation, a larger allocation or a different managed service, depending on the constraint.

Before moving, check engine and version compatibility, character sets, collations and application requirements. Prepare a data cutover so new writes are not split across two independent copies. Keep a recovery point and a clear acceptance test.

8. Control administrator access

Give people the access needed for their role and review it when work ends. Use separate authorised accounts where the platform supports them, with secure panel access and reliable recovery.

An unrelated client should not receive a shared cPanel login revealing other databases. Independent hosting accounts are generally the clearer boundary. Within an application, keep database grants focused rather than sharing one broad user across every project.

9. Assess location through the application architecture

The database is commonly queried by the application server, so latency between those services can matter. Visitor location alone does not establish the best database location or prove that a UK domain uses UK infrastructure.

Measure the relevant path and review data-handling requirements. Do not claim that a local label guarantees faster queries. If remote access is required, use the provider’s supported secure networking and authentication arrangements.

10. Test a disaster-recovery procedure

Agree the recovery point, who can authorise a restore and how service will be verified. Restore into a controlled environment and check important application functions and data relationships.

Include credentials, configuration and external dependencies in the runbook. Avoid sending real notifications or accepting payments from a test copy. Record the observed result and any supplier actions required before calling recovery ready.

Create a database through the supported panel route

In a cPanel account, use Database Wizard or the supported database-management interface if enabled. Create the database and user, assign the required privileges and copy the exact full names into the application configuration, including account prefixes.

cPanel’s documentation advises against creating databases and users directly through phpMyAdmin because they may not be mapped correctly for management and recovery. Use phpMyAdmin for appropriate inspection or manipulation of existing data with a suitable backup and authority.

Handle a database error methodically

For a connection failure, check the configured hostname, full database name, user, credentials and grants. Confirm the service is available and the account has not reached a relevant limit. Avoid changing several credentials without recording which application needs updating.

For a migration error, compare engine compatibility and the import result. For slow requests, compare query and resource evidence. A large page asset or external API delay can make the site feel slow even when the database is not the limiting factor.

Retire exports and test copies deliberately

Database exports can contain the same sensitive information as the live application. Limit access, protect storage and keep a defined purpose for copies used in support, migration or testing. A copy outside production still needs appropriate handling.

When the work ends, follow the agreed retention and deletion process. Remove temporary import files from web-accessible locations and review access granted for the task. Keep the recovery copies required by the service distinct from abandoned troubleshooting material.

Maintain the client service record

Keep the engine, database purpose, account, backup arrangement, authorised contacts and migration notes together. Store passwords separately and remove retired exports from public paths. Review information-handling responsibilities using the relevant ICO guidance.

Compare telaHosting’s current hosting resources with the application’s requirements. A reliable database service depends on supported technology, controlled access, meaningful monitoring and tested recovery, not only the presence of a database icon in the panel.