MySQL hosting is the infrastructure and operating model used to run a MySQL database for an application: compute, storage, connections, backups, monitoring, maintenance, scaling, and recovery.
For a small product team, the practical decision is usually between a managed MySQL database and self-hosted MySQL. Managed MySQL reduces database-platform operations; self-hosting gives deeper host and configuration control but makes your team responsible for patching, backups, monitoring, replication, failover, storage growth, upgrades, and recovery.
Raff Technologies supports both paths. If standard MySQL 8 capabilities fit the application, Raff Managed MySQL is the lower-operations option. If the workload requires root access, custom packages, direct filesystem access, or a topology outside the managed boundary, MySQL can also run on a Raff VM.
For most small teams, choose the operating model before comparing server sizes. Start with ownership, recovery requirements, connection demand, and workload behavior; then choose the production plan.
MySQL hosting: managed vs self-hosted at a glance
| 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 workload and your team wants to reduce repetitive database-platform work.
Choose self-hosted MySQL when a documented requirement needs operating-system access, custom packages, direct filesystem control, exact patch timing, or a custom topology.
The important distinction is ownership. A self-hosted database can be easy to create on day one and still become an operations project once it stores production data.
What managed MySQL hosting actually changes
A managed MySQL service does not remove database responsibility. It changes which layer your team operates.
The provider typically owns more of the platform work, such as:
- database provisioning;
- operating-system and service maintenance;
- backup infrastructure;
- point-in-time recovery tooling;
- service monitoring;
- storage expansion workflows;
- supported high-availability and failover controls;
- network and access-control features;
- maintenance and version workflows.
Your application team still owns:
- schema design;
- indexes;
- query performance;
- migrations;
- users and application credentials;
- connection behavior;
- data-retention decisions;
- capacity planning;
- selecting a safe recovery point;
- validating the application after recovery or failover.
This is why a managed MySQL database is most useful when database operations are required but are not the product your team is building.
Self-hosted MySQL gives control by transferring work to your team
Self-hosting can be the right architecture when a real technical or control requirement falls outside a managed-service boundary.
Common reasons include:
- root or operating-system access;
- direct filesystem access;
- exact package or patch timing;
- custom plugins or packages;
- unusual authentication requirements;
- custom replication topology;
- local processes that must run beside MySQL;
- infrastructure requirements that demand host ownership.
The trade-off is full lifecycle responsibility:
VM provisioning
+ OS hardening
+ MySQL installation
+ configuration
+ patching
+ TLS
+ firewall rules
+ monitoring
+ alerts
+ backups
+ binary-log retention
+ restore tests
+ storage growth
+ replication
+ failover
+ major upgrades
+ incident response
Installing MySQL is the easy part. Operating it reliably through growth, failures, and upgrades is the actual self-hosting cost.
For implementation, see Install MySQL on Ubuntu 24.04. If your software also supports MariaDB, review MySQL vs MariaDB for Production Apps before changing engines.
MySQL hosting should be sized from workload evidence
A production MySQL plan should not be chosen from user count or database size alone. The database must handle query work, connections, memory pressure, 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;
- expensive statements and full scans;
- data and index size;
- storage growth over time;
- 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 planning cycles.
CPU pressure can come from necessary work, but it can also come from missing indexes, inefficient joins, reports, or retry storms. Resize after checking whether the work itself can be reduced.
Memory should reflect both the working set and concurrency. MySQL uses memory for the InnoDB buffer pool, connections, sorts, temporary work, caches, and maintenance. Per-connection allocations 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 still answer queries while taking too long to restore. Recovery time is therefore part of capacity planning.
Connections and slow queries often determine the first bottleneck
A MySQL workload can run out of safe concurrency before it runs out of raw CPU.
Estimate total connection demand across the application:
maximum application instances
x pool size per instance
+ background workers
+ scheduled jobs
+ migrations
+ monitoring
+ administrative reserve
= planned connection demand
A pool of 10 connections can look small until eight application replicas and several workers create independent pools.
More connections do not guarantee more throughput. Excessive concurrency can increase memory use, lock contention, context switching, and 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;
- retry storms;
- deployment overlap.
Investigate slow queries before increasing the plan size. More CPU and memory can hide inefficient SQL temporarily, but they do not fix the underlying query pattern.
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 full 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 | Infrastructure rollback aid | A complete database-aware recovery strategy |
| Restore test | Proves procedure and duration | Prevents the original incident |
Replication is not a backup. A replica usually receives accidental deletes, destructive updates, and bad migrations along with valid writes.
Define two business targets before designing protection:
- RPO: the maximum recent data loss the business can accept.
- RTO: the maximum time the database and application can remain unavailable.
If the business needs recovery to a specific minute, the recovery design must preserve a suitable base backup plus the required binary-log history. If faster recovery from a host failure is required, high availability 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.
When managed MySQL is usually the better fit
Managed MySQL is usually the simpler starting point when:
- the application uses standard MySQL behavior;
- the team does not want to maintain the database host;
- backup and recovery infrastructure should be provider-operated;
- monitoring and slow-query visibility are valuable;
- private or tightly restricted connectivity is required;
- storage expansion should be a service workflow;
- optional high availability may be required;
- engineering time is more valuable in the application than in repetitive database operations.
This is also a total-cost decision. Comparing one raw VM with a managed MySQL database is incomplete if the VM comparison excludes backups, monitoring, standby capacity, engineering time, restore testing, patching, and on-call response.
If the managed model fits, evaluate Raff Managed MySQL rather than comparing only infrastructure prices.
When self-hosted MySQL is justified
Self-hosting becomes stronger when at least one hard requirement falls outside the managed service:
- root access is mandatory;
- direct filesystem access is required;
- a required plugin or package is unsupported;
- exact patch timing matters;
- a custom replication or failover topology is necessary;
- database operations are already a mature internal capability;
- compliance or platform requirements demand deeper host ownership.
If none of these apply, self-hosting can create an internal database platform that a small product team must maintain without creating meaningful product value.
For the broader ownership decision, see Managed vs Self-Hosted Databases.
What Raff Managed MySQL currently provides
The live Raff Managed MySQL page currently lists MySQL 8.0 with InnoDB, managed backups, continuous binary-log capture for point-in-time recovery, monitoring and slow-query insights, TLS, IP allowlists, private connectivity, storage expansion, and optional high availability using a Galera cluster.
Raff also provides a free managed-database entry point. The live MySQL page currently shows 1 GB memory, 2 GB storage, and daily backups for the free starting tier. Raff's release notes state that one free managed database per account is available across PostgreSQL, MySQL, or Valkey and that an inactive free database can pause after seven days without a connection. Current eligibility and limits should still be verified on the live product page and console.
A managed architecture can stay compact:
Application
-> private or restricted connection
Raff Managed MySQL
-> managed platform operations
-> customer-owned schema, queries, and application behavior
A self-hosted architecture on Raff VMs shifts more work to the customer:
Application VM
-> private network
MySQL VM
-> customer-operated patching, backups, monitoring, replication, HA, and recovery
The right model is the one your team can operate and recover reliably at the required service level.
MySQL hosting buying checklist
Before choosing a provider or plan, document:
- Required MySQL major version.
- Required plugins or packages.
- Current data and index size.
- Expected storage growth.
- Peak application and worker connections.
- Required RPO and RTO.
- Whether high availability is required.
- Backup retention requirement.
- Private-network or public-access requirements.
- Who owns restores and production incidents.
- Expected migration or exit path.
- Total operating cost, including engineering time.
If these are unknown, monthly plan price alone is not enough information to choose production MySQL hosting.
Conclusion
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, RPO, RTO, and restore time before choosing the production shape.
Managed MySQL is usually the practical choice 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 additional maintenance, monitoring, and recovery work.
For teams evaluating Raff, compare the live Managed MySQL service against the checklist above. If the workload requires host-level control outside the managed boundary, evaluate MySQL on a Raff VM instead.
