Platform Buying Guide
A forum is a database with a reading interface attached
The caching arithmetic every other kind of site relies on runs backwards here, and it changes what you should be buying.
The short answer
Buy database throughput, not page cache. Run phpBB or XenForo-class boards on a strong shared tier with NVMe and object caching, and give Discourse a VPS of its own — the real decision is how much you spend on database performance, because a signed-in member is a cache miss by definition.
Below: how forum load actually behaves, the two ratios that size the plan, the caching advice that is correct everywhere else and wrong here, and the tier we would run a growing board on.
By the HostingFast team · Reviewed 15 August 2026
Free
Migration, at no charge
24/7
Engineers on duty
Daily
Backup cadence
$0
Setup charge
For community builders who want the hosting sized from the traffic mix rather than from a headline visitor number. The mix is what decides this, and it is easy to measure.
Forums invert the usual caching arithmetic. Because almost every request comes from a signed-in member viewing a personalised page, database throughput and PHP worker count absorb the load a page cache handles on any other kind of site.
The two ratios that size the plan
First, the signed-in ratio. Pull a day of access logs and count how many requests carried a session cookie. On a healthy community that figure is high, and every one of those requests is a page your cache cannot serve.
Second, queries per page view. Enable the board's own debug output or read the slow query log for an hour. A thread view issuing a handful of queries is fine; one issuing dozens per post because an add-on joins on every render is a problem that grows with your success.
Multiply them and you have the real load: signed-in requests per hour times queries per request. That number, not your registered member count, is what you are buying.
It also tells you where the ceiling is. PHP worker count caps concurrency, and when workers are all busy waiting on the database, new members queue at the door rather than getting a slow page.
Why the usual caching advice is wrong here
Everywhere else, the answer to load is a page cache. Here, budgeting as though the page cache will absorb the load is the mistake that defines the category: signed-in members receive personalised pages, and personalised pages are by definition the ones a cache cannot serve.
What does work is caching a layer down. Object caching for sessions, permission sets, unread markers and hot forum metadata takes repeated lookups off the database without touching the personalisation.
A thousand blog readers mostly collect the same stored copy. A thousand forum members each trigger live queries against unread counts, permissions and personalised views. Same visitor figure, an order of magnitude more server work, and the plan has to be bought for the second shape.
The part everyone under-budgets: notification email
Retention on a forum runs through the inbox. Replies, mentions, watched threads and digests are what bring members back, and a board whose mail lands in spam quietly stops growing without any visible fault.
Which means SPF, DKIM and DMARC are a community feature rather than an administrative chore, and outbound deliverability belongs on the checklist next to database throughput.
Measure it the way you would measure anything else: send to accounts on the major providers, check where the message lands, and read the headers for the authentication results rather than assuming.
Our pick, and the honest platform boundary
Overdrive is where this page lands for a PHP board: 3.5 cores and 2.5 GB of RAM, 500 GB of disk, 100 mailboxes included, NVMe under the database, SSH from signup and staging copies for testing an add-on before the community meets it.
Discourse and its relatives are a different shape — resident processes, a background job runner, and system packages — so they belong on a VPS with root rather than on a managed account. That is the honest boundary and we would rather draw it than sell past it.
Put us through the identical checks: message support before paying and see who actually replies, compare the renewal rate with the order rate, read the refund terms in full, and look the company up — ours is Vitalcare at Home Ltd, registered in England and Wales, on the public record.
Our commercial interest, stated in the body copy
We sell hosting and say so in the body copy rather than the footer. That is what lets this page tell you where our managed tiers stop being the right answer.
Mailboxes on your own domain are part of the plan rather than a checkout line item, which matters more than usual when notifications are your retention mechanism.
- Two ratios you can measure from your own logs
- Object caching where a page cache cannot reach
- Deliverability treated as a community feature
- The boundary to a VPS stated plainly
Why HostingFast
Standard on every plan
NVMe under the database
A forum is disk-bound long before it is CPU-bound, which makes storage latency the number that decides how it feels.
Object caching where it counts
Sessions, permissions and unread markers answered from memory, which is the only cache a personalised page can use.
Mail authentication configured
SPF, DKIM and DMARC set up properly, because notification delivery is what actually brings members back.
Overdrive, without the adjectives
3.5 cores, 2.5 GB of RAM, 500 GB of disk and 100 mailboxes at one published monthly rate.
Staging before the community sees it
Test an add-on or an upgrade on a copy, because a broken permission rule on a live board is a very public failure.
A boundary we will name
Discourse-class software wants root and a VPS, and we would rather say so than sell you a managed account that fights it.
Prices Side by Side
Our numbers next to the big names
Typical intro and renewal pricing across the market, lined up against ours — including the renewal figure most comparison charts skip.
| Feature | HostingFastMost popular | Typical household-name host | Typical bargain host | Typical loss-leader deal |
|---|---|---|---|---|
| Starting price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Renewal price / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Cheapest plan renews at its sign-up price | ||||
| SSL as standard | ||||
| Migration done for you | ||||
| NVMe drives on the cheapest tier | ||||
| Daily backups from the first tier | ||||
| Real humans on support, 24/7 |
*Our number is the lowest-priced plan we sell on an annual term, pulled live from the same catalogue that powers our pricing page — it physically cannot fall out of date. The other three columns show the ranges shared hosts in each bracket typically advertise: introductory offers that mostly demand a one-to-four-year commitment, then jump once it expires. We no longer name rivals or print their prices, because a figure we cannot verify on the day you read it has no business on this page. Line us up against whichever host you are really weighing — and give the renewal row the hardest look.
Quick Start
From order to online
- 1
Count your signed-in ratio
A day of access logs, filtered for session cookies. That percentage is what decides whether page caching is a strategy or a distraction.
- 2
Read queries per thread view
Debug output or the slow query log for an hour. An add-on that joins on every post is the most common hidden cost on a growing board.
- 3
Test where notifications land
Send to accounts on the major providers and read the authentication headers. Retention runs through the inbox, so this is a load-bearing check.
- 4
Put the money on storage latency
When the budget is tight, disk latency and object caching beat every other line item on a forum. Everything else is second.
Built In
Loaded onto every plan
- NVMe SSD under MySQL rather than spinning disk
- Object caching available for sessions and hot metadata
- PHP worker headroom sized for signed-in concurrency
- SPF, DKIM and DMARC configured for outbound notifications
- Mailboxes on your own domain included with the plan
- SSH from signup, with Git already on the path
- Staging copies for testing an add-on before the community meets it
- Daily backups with restores you run yourself from the panel
- In-place upgrades, so a growing board is not a migration
- Zero setup charges — there is no joining fee, ever
Frequently Asked
What people ask us most often
How do I work out what my forum actually costs to serve?
Signed-in requests per hour multiplied by queries per request. Pull the first from a day of access logs filtered for session cookies, and the second from the board's debug output or the slow query log. That product is the load you are buying, and it is usually an order of magnitude above what the raw visitor count suggests.
If page caching cannot help, what caching can?
Object caching, one layer down. Sessions, permission sets, unread markers and forum metadata are looked up repeatedly and change rarely, so holding them in memory removes a large fraction of the query volume without touching the personalisation that made page caching impossible in the first place.
What fails first when a board suddenly gets popular?
PHP workers, not CPU. Every worker waiting on a database query is a worker unavailable to a new arrival, so the visible failure is queuing at the door rather than a slow page. The fix order is: reduce queries per view, add object caching, then add workers — in that sequence, because the last one is the expensive one.
Why does notification email belong on a hosting checklist?
Because it is the retention mechanism. A board whose replies and mentions land in spam loses members without any visible fault to investigate, and the cause sits in DNS records rather than in the software. Treat SPF, DKIM and DMARC as community infrastructure and test where messages actually land rather than assuming they arrive.
Keep reading
Hosting for Side Projects
Several projects on one account, sized by what they actually consume.
LiteSpeed Hosting
The caching layer that skips PHP entirely, and how to confirm it is working.
Uptime (Glossary)
What uptime figures mean in practice, and what they quietly exclude.
Business Hosting
Shared hosting with the full developer toolbelt: SSH, Node.js, Python and PostgreSQL.
Plesk Hosting
Shared hosting on Plesk for anyone who would rather skip cPanel.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Buy the database, not the badge.
NVMe under MySQL, object caching, real worker headroom and mail that lands — at a flat renewal rate.
View Business Hosting plans