MySQL hosting is the infrastructure and operating model used to run a MySQL database for an application, including compute, storage, connections, backups, monitoring, maintenance, and recovery.
For a small team, the useful decision is not simply which provider can run MySQL. It is who owns the database platform, how recovery works, and what happens when the workload outgrows the first plan. Managed MySQL reduces host-level operations; self-hosting gives deeper control but makes your team responsible for the full database lifecycle.
Raff Technologies supports more than 3,000 customers and 15,000 VMs across application and data workloads. In our deployment work, the recurring MySQL risk is rarely installation. It appears later in untested restores, connection growth, slow-query ownership, disk expansion, upgrades, and unclear incident responsibility.
This guide explains when managed MySQL or self-hosted MySQL is the better fit, what to measure before production, and how a free managed-database entry point can be used for evaluation before choosing a production size. For engine compatibility, use MySQL vs MariaDB for Production Apps.
MySQL hosting begins with operational ownership
Managed and self-hosted MySQL can expose the same standard MySQL protocol while assigning recurring work very differently.
| Responsibility | Managed MySQL | Self-hosted MySQL |
|---|---|---|
| Database provisioning | Provider | Your team |
| Operating-system maintenance | Provider | Your team |
| MySQL service maintenance | Provider within service policy | Your team |
| Backup platform | Provider-operated within plan scope | Your team designs and operates it |
| Point-in-time recovery | Service capability when included | Your team configures backups and binary-log retention |
| Monitoring platform | Usually included to a defined scope | Your team selects and maintains it |
| Storage expansion | Service workflow | Your team plans and executes it |
| High availability | Service option | Your team designs, tests, and operates it |
| Root and filesystem access | Restricted | Full control |
| Schema, indexes, and queries | Your team | Your team |
| Migration safety | Your team | Your team |
| Application reconnect behavior | Your team | Your team |
Choose managed MySQL when the service supports the required version and workload, and the team wants to reduce repetitive database operations.
Choose self-hosted MySQL when a documented requirement needs operating-system access, custom packages, direct filesystem control, exact patch timing, or a topology outside the managed boundary.
The important distinction is ownership. A self-hosted database can be technically simple on day one and still become an operations project once it stores production data.
MySQL hosting should be sized from workload evidence
MySQL sizing should not be based only on current database size or user count. The database must support query work, connections, cache behavior, temporary operations, binary logs, backups, maintenance, and growth at the same time.
Collect these inputs before choosing a production plan:
- peak active transactions;
- queries per second during normal and peak periods;
- p50, p95, and p99 query latency;
- frequently expensive statements;
- current data and index size;
- 30-day growth rate;
- read-to-write ratio;
- connection count and pool behavior;
- buffer-pool effectiveness;
- temporary-table and sort activity;
- storage latency and throughput;
- binary-log generation rate;
- backup duration;
- measured restore duration;
- expected growth over the next two planning cycles.
CPU pressure can come from necessary work, but it can also come from missing indexes, full scans, inefficient joins, reporting queries, or retry storms. Resize only after checking whether the work itself should be reduced.
Memory should reflect the active working set and concurrency. MySQL uses memory for the buffer pool, connections, sorts, temporary work, caches, and maintenance. Settings that allocate memory per connection can multiply quickly across a busy application.
Storage planning should include more than current table size:
data + indexes + binary logs + temporary work + expected growth + migrations and maintenance + operational safety margin
A database can serve traffic comfortably while taking too long to restore. Recovery time is therefore part of capacity planning.
Connection and query behavior often determine the first bottleneck
A production MySQL workload may run out of safe concurrency before it runs out of raw CPU.
Budget total connection demand across every component:
maximum application instances × pool size per instance + background workers + scheduled jobs + migrations + monitoring + administrative reserve = planned connection demand
A pool of 10 connections may look modest until an application scales to eight replicas and workers open separate pools. The total becomes the real database-side demand.
More connections do not guarantee more throughput. Excessive concurrency can increase memory use, lock contention, context switching, and query queueing.
Monitor:
- current and peak connections;
- threads running;
- connection errors;
- long transactions;
- lock waits and deadlocks;
- slow-query frequency;
- temporary tables written to disk;
- buffer-pool behavior;
- application retry storms;
- deployment overlap.
Slow queries should be investigated before increasing the plan size. A larger database server can hide missing indexes or unbounded reports for a while, but it does not correct them.
Backups, binary logs, replication, and HA solve different failures
MySQL recovery should separate historical recovery from service continuity.
| Control | Primary purpose | What it does not solve alone |
|---|---|---|
| Logical dump | Portable export and selected recovery | Fast recovery for every large database |
| Physical backup | Full-instance recovery | Point-in-time history without binary logs |
| Binary logs | Point-in-time recovery and replication input | A complete base backup |
| Replica | Availability and eligible read scaling | Recovery from a replicated bad write |
| High availability | Faster recovery from selected node failures | Historical recovery |
| Infrastructure snapshot | Server-level rollback support | A complete database-aware recovery strategy |
| Restore test | Proves recovery procedure and duration | Prevents the original incident |
Replication is not a backup. A replica normally receives accidental deletes, destructive updates, and bad migrations along with valid writes.
Define two targets before choosing the protection design:
- Recovery Point Objective (RPO): the maximum recent data loss the business can accept.
- Recovery Time Objective (RTO): the maximum time the database and application may remain unavailable.
If the business needs recovery to a specific minute, the backup design must preserve a suitable base backup plus the required binary-log history. If the business needs faster recovery after a host failure, a standby or managed high-availability option may be justified in addition to backups.
Use Database Backup Strategy for SaaS Apps for the wider recovery model and Zero-Downtime Database Migrations when schema or data changes affect the recovery plan.
Managed MySQL is usually the simpler small-team default
Managed MySQL is generally the stronger default when the workload fits supported versions and service capabilities and the team does not need to operate the database host.
It is a good fit when:
- the application uses standard MySQL behavior;
- no one should own database host patching;
- backup and recovery infrastructure should be provider-operated;
- monitoring and slow-query visibility should be available without assembling a separate platform;
- private or tightly restricted connectivity is required;
- storage expansion should be a service workflow;
- optional high availability may be needed later;
- engineering time is more valuable in the application than in repetitive database maintenance.
Managed does not mean the provider owns every database problem. The application team still owns:
- schema design;
- indexes;
- query patterns;
- migrations;
- application credentials;
- data retention decisions;
- connection pools;
- capacity decisions;
- validating data after a restore;
- application behavior after failover.
A useful rule is: the provider operates the database platform; your team still operates the data model and application behavior.
Self-hosted MySQL fits hard control requirements
Self-hosting makes sense when the managed boundary cannot satisfy a documented requirement.
Typical reasons include:
- root or operating-system access;
- direct filesystem access;
- exact MySQL package or patch timing;
- custom plugins or packages;
- unusual authentication requirements;
- a custom replication topology;
- local processes that must run beside MySQL;
- infrastructure controls that require host ownership.
The trade-off is complete lifecycle responsibility. The team must own:
- secure installation and configuration;
- package and operating-system updates;
- firewall and private-network rules;
- TLS and secrets;
- backup automation;
- binary-log retention;
- restore testing;
- disk growth;
- monitoring and alerting;
- replication and failover where required;
- major upgrades;
- incident response.
For implementation, use Install MySQL on Ubuntu 24.04. If the application also supports MariaDB, MySQL vs MariaDB for Production Apps covers compatibility and migration considerations before changing engines.
Self-hosting should solve a real technical or control problem. Otherwise the extra responsibility is difficult to justify for a small team.
Raff gives teams a managed MySQL path and a self-hosted path
Raff supports both operating models.
Raff Managed MySQL currently provides MySQL 8.0 with managed backups, continuous binary-log capture for point-in-time recovery, monitoring and slow-query insights, TLS, IP allowlists, private networking, storage expansion, maintenance workflows, and optional high availability. Verify the live product page and database console for current plan limits, retention, pricing, and availability before deployment.
The Raff database console also provides a free database entry point for eligible managed-database workloads. Because free-tier limits can change independently of public product copy, use the live console as the source of truth for current MySQL eligibility and capacity rather than relying on a historical article number.
A managed architecture can stay compact:
Application ↓ private or restricted connection Raff Managed MySQL ↓ Managed platform operations + customer-owned schema and queries
A self-hosted MySQL architecture uses Raff VMs:
Application VM ↓ private network MySQL VM ↓ Customer-operated backups, monitoring, patching, replication, and recovery
The first-hand pattern we use at Raff is simple: start with the smallest operating model the team can recover confidently, then add control or availability when a measured requirement justifies it.
The free managed-database entry point is useful for evaluation, learning, prototypes, and early integration work. Production sizing should still follow measured CPU, memory, storage, connections, RPO, RTO, and availability requirements.
Conclusion: choose MySQL hosting by responsibility and recovery needs
MySQL hosting is not only a provider or monthly-price decision. Start with who owns the database lifecycle, then measure connection demand, slow queries, memory pressure, storage growth, backup behavior, and restore time before choosing the production shape.
Managed MySQL is usually the practical default when the service supports the workload and the team wants a smaller operational surface. Self-hosting is justified when a specific technical or control requirement outweighs the added maintenance, monitoring, and recovery work.
Use the free managed-database entry point to evaluate the Raff workflow, then size production from evidence rather than assuming the free tier is a permanent production target. Continue with MySQL vs MariaDB for Production Apps for engine compatibility or Managed vs Self-Hosted Databases for the wider ownership framework.