SQL Hosting: What to Check Before You Pick a Managed Database

SQL hosting means renting a managed relational database, usually MySQL, PostgreSQL or SQL Server, where the provider handles the server, patching and backups while you connect your application and own the schema.

The word SQL names a language, not an engine, so the first decision is which database your application actually speaks.

SQL is the language, the engine is the decision
What managed actually means
A checklist for comparing providers
The traps behind free and cheap tiers
Connecting your application and keeping it healthy
Where RunxBuild fits
Migrating to a hosted database without losing data
How this fits the rest of the stack
FAQ

SQL is the language, the engine is the decision

People search for SQL hosting as though it were one product. It is a family of products that all understand SQL but differ in dialect, tooling and licensing. The three that matter for most web projects are MySQL, PostgreSQL and Microsoft SQL Server.

MySQL is the long-time default for PHP applications, WordPress and many content management systems. PostgreSQL has a reputation for strictness, strong standards support and rich features such as advanced indexing, JSON handling and extensions. SQL Server is Microsoft’s database, common in .NET shops and enterprise environments, and usually tied to Windows-oriented tooling and commercial licensing.

Pick the engine your software already expects. WordPress requires MySQL or a compatible fork. A Django or Rails app can use PostgreSQL or MySQL with small differences. A .NET application written against SQL Server specifics will need work to move. Changing engines later is a migration project, not a setting.

If you are starting fresh and have no constraint, PostgreSQL is a safe default for most new applications because of its feature set and ecosystem. If you are running WordPress, use MySQL. If someone hands you a project built on SQL Server, check for stored procedures and T-SQL specifics before assuming you can move it.

The existing post on the MySQL hosting service goes deeper on one engine.

What managed actually means

A managed database service takes on the repeating infrastructure jobs. The provider installs and patches the database software, runs the machine it sits on, takes automated backups, and usually offers monitoring. You keep control of data, schema, users and queries.

Compare that with running a database on a general-purpose server you rent. There you install it, tune it, secure it, schedule backups, test restores and handle upgrades. It is cheaper in line-item cost and costs far more in attention. The most common outcome of a self-run database on a small project is a backup script that quietly stopped working months ago.

Managed does not mean hands-off. You still decide indexing, query shape, connection behaviour and growth. A managed database can be brought down by an application opening too many connections or running one unindexed query against a large table. The provider keeps the server up, and it will happily keep a slow query running.

It also helps to know what you give up: root access to the operating system, the freedom to install arbitrary extensions, and sometimes the ability to run very old versions. For most web applications those are acceptable trades.

A checklist for comparing providers

When you evaluate SQL hosting, ask the same questions of every option. The answers matter more than the headline price.

Engine and version. Is the exact engine and major version you need available, and how are upgrades handled?
Backups. How often, how long are they retained, and can you restore to a point in time? Has anyone tested a restore?
Connection limits. The cap on simultaneous connections is often the first thing a growing app hits.
Storage and growth. What happens when the disk fills, and is resizing automatic or a support ticket?
Network security. Is the database private by default, with allow-listing or private networking, or open to the internet?
Location. Is it near the application? Cross-region database calls add latency to every query.
Scaling. Can you move to a bigger plan without migrating, and with how much downtime?
Access. Can you export a full dump any time, so you are never locked in?

Write the answers into a small table. The act of filling it in exposes which providers are vague about the parts that hurt in production.

The traps behind free and cheap tiers

Free and very cheap tiers are legitimate for learning and prototypes, and they carry limits you should know before depending on them.

Common restrictions include small storage caps, low connection limits, databases that pause after inactivity and take seconds to wake, shared resources with unpredictable performance, short or no backup retention, and a time limit after which the free tier ends. A database that sleeps will cause the first request of the day to time out, which looks like an application bug.

The question to ask of any free tier is what happens at the limit. Some services stop accepting writes. Some bill you automatically. Some delete the database after a period of inactivity. Read that paragraph of the terms before you put real data in.

A sound approach is to use the free tier for development and a paid plan for anything with real users. The price difference is small compared with the cost of one lost day of data. If you want to see how cost scales with plan size on one platform, the calculator lists the actual tiers.

Connecting your application and keeping it healthy

Once you have an instance, the connection details are a host, port, database name, username and password, usually delivered as a single connection string. Store it as an environment variable. Never commit it to a repository.

postgres://app_user:[email protected]:5432/appdb

A few habits pay off immediately. Create a dedicated database user for the application with only the privileges it needs, instead of using the admin account. Use a connection pool in the application so each request does not open a new connection. Set sensible timeouts on queries so a slow one cannot pile up. And enable TLS for connections that leave a private network.

Run migrations through a tool rather than editing the schema by hand, so changes are versioned and repeatable. Take a manual backup before any large migration and confirm it can be restored. Finally, watch the basics: connection count, slow queries and disk use. They are the three numbers that predict most outages.

Where RunxBuild fits

RunxBuild offers managed MySQL and Postgres, and nothing else, so it is the right fit if your application speaks one of those two. Instances come with connection limits, backups, user management and private networking, and they sit beside your web services in the same dashboard. A service can reach its database over a private connection rather than the open internet.

If you specifically need SQL Server, this is not the platform for it, and you should look for a provider that offers that engine. For WordPress, managed WordPress on its own plan ladder includes a database browser in the dashboard with tables, rows, SQL, export and import.

The docs on databases explain backups and connections for both engines. Choose the engine first, then the plan.

Migrating to a hosted database without losing data

Moving an existing database to hosting is a routine job when you treat it as a rehearsal followed by a cutover. Export a full dump from the source with the engine’s native tool, such as mysqldump for MySQL or pg_dump for PostgreSQL, and import it into a fresh hosted instance. Then point a copy of the application at the new instance and run through the main flows.

The rehearsal exposes the usual snags: character set and collation differences, missing extensions, users and privileges that were not part of the dump, and version differences that change behaviour. Fix them on the copy, not on production.

For the cutover, pick a quiet window, stop writes to the old database, take a final dump, import it, switch the connection string and watch the logs. Keep the old database untouched for a few days as a fallback. Larger databases may need replication to shorten the downtime window, which is a project of its own. Measure the dump and import time during the rehearsal so the real window holds no surprises.

How this fits the rest of the stack

The cheapest database is the one that matches the plan your traffic really needs, and the calculator is how you find that number before the invoice does. Run your engine, storage and connection needs through the RunxBuild hosting calculator. When the shape is clear, the RunxBuild dashboard is where a MySQL or Postgres instance gets created.

Useful related references:

FAQ

What is SQL hosting?

It is a managed service that runs a relational database for you, typically MySQL, PostgreSQL or SQL Server. The provider handles the server, patching and backups while you manage your schema, data and queries.

Which SQL database should I choose?

Match your application. Use MySQL for WordPress and many PHP apps, PostgreSQL for most new applications, and SQL Server only if your software requires it. Changing engines later is a migration project.

Is free SQL hosting safe for production?

Usually not. Free tiers tend to have small limits, sleeping databases, little or no backup retention and a possible end date. Use them for learning and prototypes, then move to a paid plan for real users.

How are managed databases different from running my own?

The provider patches the software, runs the machine and takes backups. You keep control of the data and queries. Self-hosting costs less per month and more in attention, especially for backups and upgrades.

What should I check before choosing a provider?

The exact engine version, backup retention and restore options, connection limits, private networking, storage growth behaviour and whether you can export a full dump at any time.