VPS Hosting for Moodle and LMS: CPU, RAM and Database Sizing

Moodle and other LMS platforms can look lightweight from the outside: a few courses, some videos, a quiz here and there. But the moment real users start clicking “Start quiz” at the same time, CPU, RAM and database performance become the difference between a smooth learning experience and a support nightmare. In this guide, we’ll walk through how to size a VPS correctly for Moodle and similar LMS workloads, focusing on vCPU, RAM and database requirements for different sizes of deployments. We’ll look at realistic scenarios, explain what “concurrent users” really means in practice, and show how to plan an architecture that can grow from a small training portal to a serious multi‑faculty environment. As dchost.com, we see the same patterns again and again: under‑estimated CPU for quiz peaks, not enough RAM for the database buffer pool, and storage that simply can’t keep up with I/O. This article is our practical playbook to avoid those mistakes from day one.

Why VPS Hosting Fits Moodle and LMS Platforms

From a hosting perspective, Moodle and most LMSs are classic stateful web applications: PHP (or similar) on the application side, a relational database, file storage for course content and user uploads, plus optional caching and search components. A VPS is often the sweet spot for this stack, especially when you need more control than shared hosting offers, but don’t yet want the complexity of a multi‑server cluster.

With a VPS, you control:

• vCPU allocation – how many cores you dedicate to PHP, web server processes and background tasks.
• RAM distribution – how much memory you reserve for PHP workers vs database buffer pools vs caching layers.
• Storage and IOPS – SSD or NVMe disks, file system layout, separate volumes for database vs content.
• Network and security – firewall rules, TLS configuration, VPNs and remote access policies.

That control is exactly what Moodle and LMS platforms need to stay predictable under load. Shared hosting hides (and often limits) CPU and RAM usage per account. dedicated servers give full control but may be overkill at the early stages. VPS hosting, especially when it’s easy to resize up or move to a larger node, lets you start with a sensible baseline and grow with your users.

Key Resource Types for Moodle: CPU, RAM, Storage and Database

Before jumping into sizing tables, it helps to understand where resources are actually consumed inside Moodle or a typical LMS.

CPU: Where the Cycles Go

CPU time is mainly spent in:

• PHP execution – rendering course pages, processing quiz attempts, grading, report generation.
• Web server overhead – Nginx or Apache handling TLS, HTTP/2, compression and logging.
• Database queries – parsing, planning and executing SQL, especially for reporting and gradebook views.
• Background tasks – Moodle’s cron, scheduled reports, email sending, backup jobs.

LMS traffic is bursty: for example, everyone starting a timed quiz at the same minute. CPU sizing needs to account for these short peaks rather than just average daily traffic.

RAM: PHP Workers, Database Buffers and Caches

RAM is critical because low memory doesn’t just slow things down – it can cause processes to crash or the kernel’s OOM killer to terminate your database. Memory is used by:

• PHP workers – each PHP‑FPM/Apache worker has its own memory footprint.
• Database buffer pools – MySQL/MariaDB or PostgreSQL caching tables and indexes in memory.
• File system cache – the OS caching frequently accessed PHP files and course content.
• Caching layers – Redis or Memcached for sessions or application cache, if you use them.

If you haven’t seen it yet, our article on managing RAM, swap and the OOM killer on VPS servers goes deeper into how Linux behaves when memory runs low – useful background when planning an LMS server.

Storage and IOPS: More Than Just Disk Size

LMS platforms typically store:

• Database data – tables for users, enrolments, grades, attempts, logs.
• Course files – PDFs, slides, images, SCORM packages.
• Media – video and audio (sometimes offloaded to external storage or streaming platforms).
• Backups – full course backups, automatic site backups.

For performance, disk speed and IOPS matter more than pure capacity. NVMe or high‑quality SSD storage is strongly recommended for Moodle’s database and application files, while large media libraries can be offloaded to object storage or external systems if needed.

Database: The Real Bottleneck Under Load

Moodle is database‑heavy. Pages that look simple – a course overview, a grade report – may trigger dozens of queries in the background. When you increase concurrent users, you’re really increasing concurrent queries. That’s why vCPU and RAM sizing must always consider database needs, not just PHP.

If you want a broader comparison of database engines, our article on MariaDB vs MySQL vs PostgreSQL for web applications gives a practical overview that also applies to Moodle deployments.

Understanding Concurrent Users for Moodle and LMS

One of the most common sources of confusion in LMS sizing is the phrase “concurrent users”. A site with 5,000 registered students does not mean 5,000 concurrent users.

For capacity planning, we usually define concurrent users as:

• Users who have made at least one active request in the last 5 minutes (page view, quiz action, upload etc.), and
• Users who are actively interacting at the same time, not just logged in with a tab open in the background.

In practice, many institutions see peak concurrency like:

• Up to 30–50 concurrent users for a small school with 500–1,000 registered students.
• 100–300 concurrent users for a faculty or mid‑sized training portal with a few thousand students.
• 500+ concurrent users for university‑wide platforms or large enterprises.

We’ll use these ranges in the sizing examples below. If you want a more general look at resource estimation, our guide on how many vCPUs and how much RAM you really need complements this article well.

Baseline VPS Sizing for Moodle and LMS Deployments

These are starting points based on what we regularly see on dchost.com VPS plans. Real requirements depend on course design (heavy quizzes vs video), plugins, and peak usage patterns, but these scenarios give a solid baseline.

Scenario 1: Small School or Pilot Project

• Registered users: up to 500
• Peak concurrent users: ~20–30
• Usage pattern: primarily course browsing, occasional quizzes, light reporting

Recommended VPS specs:

• vCPU: 2 vCPUs
• RAM: 4 GB
• Storage: 80–120 GB SSD/NVMe (OS + database + Moodledata)
• Database: Single MySQL/MariaDB or PostgreSQL instance on the same VPS

On this size, it’s reasonable to run everything on a single VPS: Nginx/Apache, PHP‑FPM, database and cron. Focus on correct PHP limits (memory_limit, max_execution_time) and regular backups.

Scenario 2: Corporate Training Portal or Medium‑Sized School

• Registered users: 1,000–3,000
• Peak concurrent users: 50–100
• Usage pattern: frequent quizzes, SCORM packages, regular completion reports

Recommended VPS specs:

• vCPU: 4 vCPUs
• RAM: 8 GB
• Storage: 150–250 GB SSD/NVMe
• Database: Still acceptable on the same VPS, but allocate at least 3–4 GB RAM to the database buffer pool.

At this tier, CPU spikes happen during exams and mandatory training deadlines. PHP‑FPM worker counts and database connection limits become more important. You’ll also start to benefit from a dedicated cache store (Redis) for sessions and application cache.

Scenario 3: Faculty‑Level Moodle or Large Training Department

• Registered users: 3,000–10,000
• Peak concurrent users: 100–300
• Usage pattern: heavy quiz usage, simultaneous exams, large gradebooks and reports

Recommended starting specs (single VPS, but near the upper limit):

• vCPU: 6–8 vCPUs
• RAM: 16 GB
• Storage: 250–500 GB NVMe (especially for database and Moodledata)
• Database: Ideally move to a separate VPS at this stage; see the architecture section below.

Here, the main risk of staying on a single VPS is that CPU‑intensive PHP tasks and database operations compete for the same cores. Separating application and database roles gives clearer performance and easier scaling.

Scenario 4: University‑Wide or Enterprise LMS

• Registered users: 10,000–50,000+
• Peak concurrent users: 300–1,000+
• Usage pattern: multiple faculties or business units, high concurrency during exam windows, extensive reporting and integrations

At this level, you’re typically beyond a single VPS and into multi‑VPS or dedicated server architecture:

• App tier: 2+ VPS nodes, each with 8+ vCPUs and 16–32 GB RAM, behind a load balancer.
• Database tier: 1–2 VPS or dedicated servers, 8+ vCPUs and 32–64 GB RAM, possibly with replication and read replicas.
• Cache tier: Dedicated Redis/Memcached instance.

Even if you’re not there yet, it’s worth planning your Moodle setup so that moving to this architecture later is straightforward (for example, by separating web root, Moodledata and database from day one).

CPU Planning for Moodle on a VPS

The rough relationship between CPU and concurrency for Moodle‑style workloads is:

• Light usage (browsing, small quizzes): ~10–20 concurrent users per vCPU.
• Heavy usage (large timed quizzes, complex reports): ~5–10 concurrent users per vCPU.

This is not a hard rule, but it’s a useful sanity check. If you expect 100 concurrent users hitting quizzes, planning for at least 8 vCPUs gives room for PHP, database and background tasks.

PHP‑FPM Worker Counts

On a typical Nginx + PHP‑FPM setup, each PHP‑FPM worker handles one request at a time and consumes a certain amount of RAM. A simple starting approach is:

• Estimate average memory per PHP process (e.g. 80–120 MB with common plugins).
• Decide how much of your RAM you can allocate to PHP (for example, 3 GB out of 8 GB).
• Set pm.max_children = (PHP RAM) / (memory per process), then adjust based on monitoring.

For example, on an 8 GB VPS you might allocate ~3 GB to PHP and see 100 MB per process on average:

• 3,000 MB / 100 MB ≈ 30 PHP workers

If you want to go deeper into PHP‑FPM tuning, many of the ideas in our PHP‑focused articles (e.g. OPcache, FPM pool settings) also apply to LMS platforms, and we cover Moodle‑specific tuning separately in our Moodle and LMS hosting performance guide for PHP, database and caching.

RAM Planning and Database Requirements

For Moodle, RAM is usually split among:

• Operating system and file system cache (1–2 GB minimum).
• PHP‑FPM processes (as calculated above).
• Database buffer pool and caches.
• Redis/Memcached if used.

How Much RAM for the Database?

A common rule of thumb for MySQL/MariaDB or PostgreSQL on an LMS VPS:

• Small instance (4 GB RAM total): 1–1.5 GB for database buffer pool.
• Medium instance (8 GB RAM total): 3–4 GB for database.
• Larger instance (16 GB RAM total): 6–8 GB for database.

For busy Moodle sites, the database often ends up using at least 40–50% of total VPS RAM, especially once you have large quiz attempt tables and logs.

Choosing Between MySQL/MariaDB and PostgreSQL

Moodle supports both MySQL/MariaDB and PostgreSQL. All three work well when tuned correctly. In the field, we commonly see:

• MariaDB/MySQL: very common, many admins already familiar, good tooling, plenty of documentation.
• PostgreSQL: attractive for some teams for standards compliance and advanced query features.

The important part is to tune your chosen engine for LMS‑style workloads: sufficient buffer pool size, appropriate connection limits, and slow query logging enabled so you can spot bottlenecks.

Connections and Pooling

If you run everything on a single VPS, you may rely on Moodle’s own database connections directly. For larger setups or multiple app servers, using a connection pooler (such as PgBouncer in transaction mode for PostgreSQL) can reduce the overhead of many short‑lived connections. This matters most when concurrency grows into the hundreds.

Example VPS Architectures for Moodle and LMS

Stage 1: All‑in‑One VPS

This is where most projects start and where many small schools stay for years:

• Single VPS (2–4 vCPUs, 4–8 GB RAM).
• Nginx or Apache + PHP‑FPM, database, Redis (optional) and cron all on the same node.
• Regular off‑site backups.

Keep the architecture clean from day one:

• Separate directories for moodledata and web root.
• Use proper config management or at least a clear documentation of custom changes.
• Plan your backup strategy so it can later be extended to multiple servers.

Stage 2: Split Application and Database VPS

When CPU and RAM usage start to climb, the first big step is separating the database onto its own server:

• App VPS: 4–8 vCPUs, 8–16 GB RAM – Nginx/Apache, PHP‑FPM, Moodle code, Moodledata, Redis.
• DB VPS: 4–8 vCPUs, 16–32 GB RAM – MySQL/MariaDB or PostgreSQL, tuned for large buffer pools.

Advantages:

• Database no longer competes with PHP for RAM and CPU.
• Each tier can be scaled independently (for example, upgrade only the DB VPS when reports slow down).
• Maintenance windows can be managed separately.

We discuss the decision of moving to a dedicated database server in more depth in our article on when to separate database and application servers for MySQL and PostgreSQL.

Stage 3: High‑Availability and Scaling Out

For university‑wide and mission‑critical LMS setups, you gradually move towards:

• Two or more application VPS nodes behind a load balancer.
• A primary database server with one or more replicas (for read traffic and failover).
• Dedicated caching and possibly a separate search server if you use advanced search plugins.

Our guide on load testing your hosting before traffic spikes is particularly relevant here: you want to validate capacity and failover behaviour before exam week, not during it.

Performance Tuning Tips Specific to Moodle and LMS

Sizing is only half the story. Even a well‑sized VPS can feel slow if it’s not tuned for the particular access patterns of an LMS.

1. Use PHP 8.x and OPcache Properly

Modern Moodle versions benefit significantly from PHP 8.x performance improvements. Make sure:

• OPcache is enabled with enough memory to store compiled scripts.
• opcache.validate_timestamps is configured for a balance of performance and development convenience.
• PHP memory limits are high enough for complex operations but not so high that a single runaway process can exhaust all RAM.

2. Enable and Configure Caching

Moodle has its own caching subsystem. Even on a single VPS, using Redis for session and application cache can reduce database load and improve response times, especially under spikes when many users are loading the same course or quiz.

3. Keep the Database Clean and Indexed

Over time, logs and temporary data can grow aggressively. Consider:

• Configuring log retention periods appropriate for your compliance needs.
• Regularly checking slow query logs and adding indexes where necessary.
• Vacuuming/analyzing (PostgreSQL) or optimizing tables periodically for very large instances.

On larger setups, database‑level replication (for read scaling and failover) becomes relevant. We cover the basics of setting this up in our article on MySQL and PostgreSQL replication on VPS servers.

4. Watch RAM, Swap and IOwait

Even if CPU looks fine, high IOwait or aggressive swap usage will slow Moodle to a crawl. Monitor:

• Actual RAM usage vs total and free.
• Swap‑in / swap‑out rates, not just swap size.
• IOwait as a percentage of CPU time – persistent values above a few percent under load warrant investigation.

Again, our guide on RAM, swap and the OOM killer on VPS servers gives detailed techniques for diagnosing and fixing memory‑related slowdowns.

5. Schedule Heavy Tasks Outside Peak Hours

Moodle cron tasks (backups, report generations, automated enrolments) can be resource‑intensive. On busy platforms, it’s wise to:

• Run full site backups and heavy reports during off‑peak hours.
• Use incremental backups where possible.
• Stagger tasks so they don’t all run at the same minute.

Backups, Scalability and Future‑Proofing

Backup Strategy

LMS data is usually business‑critical: grades, completion records, compliance training proof. Treat backups as non‑negotiable:

• Automated daily database backups, stored off‑server.
• Regular file backups (Moodledata, configuration files).
• Periodic restore tests to a staging VPS so you know your backups actually work.

At dchost.com we often combine VPS snapshots with logical database dumps for a layered approach. This aligns with the 3‑2‑1 backup principles we discuss in more depth in our other backup‑focused articles.

Vertical vs Horizontal Scaling

On VPS hosting, your first scaling moves will usually be vertical:

• Increase vCPU and RAM on the same VPS as concurrency grows from 20 → 50 → 100 users.
• Upgrade storage from SSD to NVMe or add more capacity as course content expands.

Once you get into the 100–300 concurrent user range, you’ll start to see benefit from horizontal moves:

• Splitting the database onto a dedicated VPS.
• Adding a second application VPS behind a load balancer.

Because we operate both VPS and dedicated server infrastructure at dchost.com, we regularly help Moodle clients move from a single node to a multi‑VPS or even hybrid architecture when the time is right.

Putting It All Together: A Practical Sizing Checklist

When you plan or review Moodle/LMS hosting on a VPS, walk through this checklist:

1. Estimate concurrency: realistic peak concurrent users during exams or deadlines.
2. Map concurrency to vCPU: start with 5–20 users per vCPU depending on workload; round up generously.
3. Plan RAM:
   • Reserve 1–2 GB for OS and file cache.
   • Allocate enough for PHP workers (based on memory per process).
   • Give database at least 40–50% of remaining RAM.
4. Choose storage: SSD/NVMe, with enough IOPS and headroom for content growth and backups.
5. Decide the architecture stage: all‑in‑one VPS vs split app/DB vs multi‑VPS with replication.
6. Configure caching: OPcache, Moodle cache stores, optionally Redis for sessions/data.
7. Set up monitoring and load testing: watch CPU, RAM, IOwait and run test loads before high‑stakes exams.
8. Implement backups: automated, off‑site, and tested restores.

Conclusion: A Calm Path to Reliable Moodle VPS Hosting

Hosting Moodle or any serious LMS on a VPS does not have to be a guessing game. When you break the problem down into CPU, RAM, database and storage needs – and tie those to realistic concurrent user numbers – a clear sizing picture emerges. Start small but not tiny, keep an eye on memory and database health, and be ready with a plan for when concurrency doubles. That’s far easier than trying to rescue an overloaded server in the middle of exam week.

As the dchost.com team, we see Moodle and LMS workloads every day across different industries and sizes. The patterns in this guide come directly from that experience. If you’re planning a new platform, migrating from shared hosting, or wondering whether it’s time to split your database onto its own VPS, we’re happy to review your current metrics and help design a roadmap. When you pair sensible VPS sizing with good performance tuning and a solid backup strategy, your LMS becomes something everyone can rely on – quietly, in the background, exactly as it should be.