SQLite uses zero RAM when idle and about 5–15 MB per active connection, requires no daemon, no configuration, and no separate install. MySQL on the same server needs 150–300 MB of RAM just for the database process, plus a configuration pass and a running service to babysit. On a 1 GB budget VPS, that difference is 15–30% of your total memory — which is why SQLite is not a toy, it is a legitimate cost optimization for the right workloads. It is also why the default answer to “which database should I install?” should be “none, until the app tells you otherwise.”
The reflex to install MySQL on every server comes from shared hosting habits, not from need. If your application reads more than it writes, or you run a single-process tool like a dashboard, a personal wiki, or a small internal app, SQLite is almost always the better fit on a small VPS. If you are still choosing the VPS itself, our comparison table will help you find a plan with enough RAM for whichever database you pick.
What Each Database Costs You on a Small Server
The operational cost difference is larger than the memory numbers suggest. Here is the realistic picture on a $5–$6/month, 1 GB plan:
| Factor | SQLite | MySQL / MariaDB |
|---|---|---|
| RAM footprint | 5–15 MB in use | 150–300 MB baseline |
| Setup time | Zero — it is a library | 30–60 minutes including tuning |
| Backup | Copy one file, or .backup command | mysqldump or physical backup |
| Concurrent writers | One at a time (WAL allows readers) | Many, with row-level locking |
| Disk usage | One file, no logs to manage | Data + binary logs + InnoDB files |
For a low-traffic application, the MySQL column buys you almost nothing you will use. The RAM it consumes could be holding a page cache instead, which improves every request the site serves. Backups are where the gap shows up most painfully: SQLite’s entire database is one file, so a consistent backup is a single command, while MySQL requires coordinating dumps with binary logs:
# SQLite: one file, one command
sqlite3 myapp.db ".backup 'backup-$(date +%F).db'"
# MySQL: dump + log position if you want point-in-time recovery
mysqldump --single-transaction myapp > myapp-$(date +%F).sqlWorkloads That Fit SQLite
SQLite shines when the write rate is low and the data fits comfortably in memory. Practical examples on a budget VPS:
- Personal or team wikis and note tools (e.g., a small BookStack or Outline-style app at low volume).
- Analytics dashboards that ingest a few hundred events per minute or less.
- Internal tools: inventory trackers, URL shorteners for personal use, bot backends.
- Read-heavy public sites where content rarely changes — SQLite handles thousands of concurrent readers.
A useful rule of thumb: if your application can lose up to one second of writes in a crash without a problem, SQLite’s durability trade-offs are acceptable. Enable WAL mode and set a busy timeout and most of the practical limitations disappear:
PRAGMA journal_mode=WAL;
PRAGMA busy_timeout=5000;
PRAGMA synchronous=NORMAL;WAL mode is the setting that changes everything: readers no longer block the writer, so a public site can serve thousands of reads while a background job writes. The single-writer rule still applies, so batch your writes — queue them in memory and flush every few seconds rather than writing row by row. Applications that respect that pattern run comfortably for years on SQLite at traffic levels that would make most people reach for a client-server database.
When You Need MySQL Instead
Switch to MySQL or MariaDB when any of these are true:
- Multiple processes or servers write to the same database concurrently.
- The application expects a network database (PHP apps, most CMS plugins, ORMs that assume MySQL).
- You need user-level permissions, replication, or point-in-time recovery.
- You plan to grow past roughly 10,000 writes per minute, where SQLite’s single-writer lock becomes a bottleneck.
The migration path is well worn: mysqldump for the data and a config change for the app. You can also run SQLite first and move to MySQL later without rewriting your schema, because most frameworks abstract the database layer. If you do end up on MySQL, keep it lean on a small VPS: set innodb_buffer_pool_size to 25–30% of RAM instead of the default, disable query cache on MySQL 8+, and log slow queries for a week to find the queries that actually justify the database’s memory footprint.
The Verdict on a Budget
Start with SQLite unless the application forces MySQL on you. You save RAM, avoid a service to monitor, and keep backups trivial — and you can migrate later if the workload changes. If your application genuinely needs MySQL, budget for 2 GB of RAM so the database is not starved. Providers like Contabo offer large-RAM plans at budget prices that make the 2 GB tier affordable. Either way, check the plan specs side by side and make sure the RAM you save on the database is the RAM you spend on caching.
