A database hosting service gives an application a remote database endpoint without requiring the application team to own every layer of the database host. For production use, the important differences between providers are recovery, availability, networking, scaling, pricing, migration support, and what the provider actually operates after deployment.
Raff offers managed PostgreSQL, MySQL, Valkey, ClickHouse, and Kafka, while teams that need host-level control can self-host a database on Raff VM. If you are still deciding between those operating models, start with Managed Database vs Self-Hosted. This guide assumes you want database hosting and focuses on how to evaluate the service itself.
A production database hosting service should cover the full lifecycle
A production database hosting service should provide more than a running PostgreSQL, MySQL, Valkey, ClickHouse, Kafka, or another database process.
Evaluate whether the service provides:
- supported database engines and versions;
- clear compute, memory, and storage sizing;
- backups and a documented restore path;
- point-in-time recovery where supported;
- monitoring and query visibility;
- TLS and access controls;
- private networking options;
- storage expansion;
- high availability or replica options;
- maintenance and version-upgrade policy;
- migration support;
- predictable billing.
A database can be easy to create and still be difficult to operate safely. The buyer decision should focus on the production lifecycle, not only provisioning speed.
Database hosting and ordinary web hosting solve different problems
The phrase "database hosting" is used for several different products.
| Hosting model | What you get | Typical fit |
|---|
| Shared web-hosting database | Database bundled with a website plan | Small websites with limited database requirements |
| Database on a VM/VPS | Full host and database control | Teams that need root access or custom configuration |
| Managed database service | Database endpoint plus provider-operated platform tasks | Production apps that want lower operational overhead |
| Serverless database | Usage-based or autoscaling database abstraction | Variable workloads where the engine and service model fit |
For most production SaaS and business applications, the practical comparison is between a managed database service and operating the database directly on a VM.
This page focuses on the managed-service buyer decision. For VM-based database hosting, use VPS Database Hosting.
Engine fit should come before provider branding
Choose the database engine before comparing provider features.
| Workload | Common starting engine |
|---|
| General SaaS or transactional application | PostgreSQL |
| Existing MySQL ecosystem, WordPress, or Laravel workloads | MySQL |
| Cache, sessions, queues, or rate limits | Valkey or Redis-compatible |
| Analytical workloads | ClickHouse |
| Streaming or event backbone | Kafka |
| Document-oriented workloads | MongoDB |
The provider should support the engine version and capabilities your application actually uses.
Check:
- exact major version;
- required extensions or plugins;
- collations and character sets;
- connection protocol and client compatibility;
- replication or HA model;
- supported backup and recovery features;
- migration path from the current database.
Do not choose a provider first and then force the application into whichever engine happens to be easiest to buy.
Backups are useful only when the restore path is understood
A database hosting service should explain both how backups are created and how recovery works.
Ask:
- How often are backups created?
- How long are they retained?
- Is point-in-time recovery available?
- Can you restore to a new database without overwriting production?
- What is the expected restore workflow?
- Are backups included in the plan price?
- Is restore testing supported?
For a transactional production database, the recovery conversation should include:
- RPO: how much recent data the business can lose;
- RTO: how long recovery may take;
- historical recovery after accidental changes;
- restore validation;
- application reconnect behavior.
Replication does not replace backups. If an accidental delete or destructive migration reaches the primary database, replicas can reproduce the same change.
Use Database Restore Testing for a deeper recovery framework.
High availability should describe failure behavior clearly
"High availability" can mean different things across services.
Ask what happens when the primary database node fails:
- Is there a standby or replica?
- Is failover automatic?
- Does the application endpoint remain the same?
- How much data can be lost during failover?
- How long does promotion normally take?
- Is the standby synchronous or asynchronous?
- How is HA priced?
- Is failover tested by the provider?
A buyer should be able to describe the failure path before enabling HA.
For a small team, a simpler HA model with a clear responsibility boundary can be easier to operate than a topology with more configuration but unclear ownership.
Private networking should be part of the production design
A production database normally should not require broad public exposure.
A common architecture is:
Internet
↓ HTTPS
Application
↓ private network
Managed database
Evaluate whether the database hosting service supports:
- private endpoints or VPC connectivity;
- TLS for external connections;
- IP allowlists;
- scoped database credentials;
- credential rotation;
- connection auditing or access visibility.
Private networking reduces unnecessary public routing but does not replace database authentication, least privilege, or TLS requirements.
If your application runs on Raff, Raff VPC provides a private-network path between supported services and compute resources.
Connection limits can be a production bottleneck
A database hosting plan can have enough compute and still fail because application connections are exhausted.
Estimate total demand across all processes:
application replicas × pool size
+ background workers
+ scheduled jobs
+ migrations
+ admin sessions
+ monitoring
= possible connection demand
Ten application replicas with a pool of 20 connections can create 200 possible database connections before workers or administrative sessions are counted.
When evaluating a provider, ask:
- connection limit per plan;
- whether pooling is included;
- whether a proxy or pooler costs extra;
- how scaling affects connection limits;
- whether idle connections can be controlled;
- how maintenance or failover affects client reconnects.
The useful plan is the one whose resource and connection model matches the application, not simply the one with the largest RAM number.
Storage cost should include growth, backups, and operational headroom
Database storage needs capacity for more than table data.
Plan for:
data
+ indexes
+ transaction logs / WAL / binary logs
+ temporary work
+ migrations
+ backup and recovery overhead
+ expected growth
When comparing database hosting cost, check whether the advertised price includes:
- base storage;
- storage expansion;
- IOPS or performance tiers;
- backups;
- backup overage;
- snapshots where applicable;
- network transfer;
- HA standby resources;
- monitoring or query insights.
A low base price can become a larger production bill when critical capabilities are separate line items.
Predictable pricing is part of the production decision
Database hosting cost usually follows one of three models:
| Pricing model | Strength | Trade-off |
|---|
| Fixed plan sizes | Easier budgeting | Can overprovision intermittent workloads |
| Usage-based or serverless | Can fit variable workloads | Monthly cost can be harder to predict |
| Component-based | Fine-grained control | Compute, storage, I/O, transfer, proxies, and backups can become separate charges |
Before choosing a provider, model the expected production bill with:
- required RAM and vCPU;
- required storage;
- HA enabled if needed;
- backup retention;
- network transfer;
- connection pooling or proxy;
- monitoring;
- expected growth.
Raff paid PostgreSQL, MySQL, and Valkey plans start at $7.99/month. Current paid ClickHouse plans start at $59.99/month, while Kafka starts at $79.99/month. Use the live pricing page before purchase because plan sizes and commercial terms can change.
Migration support can reduce switching risk
The difficult part of changing database hosts is often not provisioning the new database. It is moving production data safely.
A useful provider migration path should address:
- source and target engine versions;
- baseline data copy;
- ongoing-write synchronization when needed;
- replication or change-capture compatibility;
- final cutover;
- validation;
- rollback;
- application endpoint changes.
Ask whether migration support is included, paid, self-service, or documentation-only.
For important production databases, migration assistance can reduce switching risk and engineering time. Use Database Migration Checklist for Managed Databases before moving a production workload.
Customer pattern from Raff: in small-team infrastructure discussions, database hosting decisions usually become clearer once recovery ownership and peak connection demand are written down before comparing plans.
Support quality matters during incidents and migrations
Database hosting is an infrastructure product, so support quality should be evaluated around failure conditions rather than sales responsiveness.
Ask:
- Can you reach a real engineer?
- Is support ticket-only?
- Is migration help available?
- Can support help explain failover or restore workflows?
- Is there an SLA?
- How are incidents communicated?
- Can the team explain which layer is provider-owned and which remains customer-owned?
A provider should not promise to optimize your schema or application automatically. It should be clear who owns the database host, backups, maintenance, failover platform, and service-level incident response.
Free database hosting is useful for compatibility testing
Free database hosting can be valuable for:
- testing an ORM or driver;
- validating engine compatibility;
- development and staging;
- prototyping migrations;
- evaluating provider UX and networking.
It should not be treated as proof that the production plan will satisfy recovery objectives, connection demand, storage growth, availability requirements, or support needs.
Raff currently provides permanent free tiers for three managed engines:
| Engine | Free tier | Main ceiling |
|---|
| PostgreSQL | $0/month, 1 vCPU, 1 GB RAM, 2 GB storage | 60 direct connections, 200 pooled connections |
| MySQL | $0/month, 1 vCPU, 1 GB RAM, 2 GB storage | 60 connections |
| Valkey | $0/month, 512 MB memory, 2 GB storage | 500 connections |
ClickHouse and Kafka do not currently have free tiers.
Use the free tier to validate the application path, then size production from actual memory, storage, connection, recovery, and availability requirements.
A provider comparison matrix should use workload-specific requirements
Instead of assigning arbitrary universal weights, classify each requirement by how important it is to your workload.
| Requirement | What to verify | Your priority |
|---|
| Engine and version fit | Exact engine, version, extensions, protocol | Required / preferred / optional |
| Recovery | Backups, PITR, restore workflow, retention | Required / preferred / optional |
| Availability | HA topology, failover behavior, endpoint continuity | Required / preferred / optional |
| Networking and security | Private access, TLS, allowlists, credential controls | Required / preferred / optional |
| Cost predictability | Full production estimate, storage, HA, transfer | Required / preferred / optional |
| Scaling and connections | Compute growth, storage growth, connection ceilings | Required / preferred / optional |
| Migration and support | Migration assistance, rollback support, escalation path | Required / preferred / optional |
A requirement marked "required" should act as a gate. A provider that misses it should not compensate by scoring higher on a less important feature.
Raff's managed database path is designed for a clear operating boundary
Raff Managed Databases currently supports PostgreSQL, MySQL, Valkey, ClickHouse, and Kafka.
The platform also gives teams an alternative operating model. If the workload needs root access, custom packages, direct filesystem control, or a topology outside the managed-service boundary, the engine can run directly on Raff VM.
A practical decision path is:
Want provider-operated database platform tasks
-> Raff Managed Databases
Need host-level database control
-> self-host on Raff VM
The commercial decision should still be made from the workload: engine compatibility, recovery, connection demand, availability, storage growth, migration risk, and operating responsibility.
Production database hosting checklist
Before choosing a database hosting service, confirm:
Database hosting services should be compared by production responsibility
A database hosting service should be evaluated by engine support, recovery, availability, networking, scaling, pricing, migration support, and the responsibility boundary after deployment.
Start with exact engine compatibility. Then compare the complete production configuration: backups, PITR, HA, storage growth, connection limits, private networking, migration, support, and the expected monthly cost.
For Raff, permanent free PostgreSQL and MySQL tiers provide a $0 path for compatibility testing, while paid PostgreSQL, MySQL, and Valkey plans start at $7.99/month.
Use Managed Databases when you want more database-platform operations handled by the provider, or Raff VM when host-level control is a hard requirement.
Sources
