SQLite vs MySQL for Self-Hosted Ghost: When to Switch

Ghost supports two database engines: SQLite for simplicity and MySQL for production scale. The choice is not religious—it is operational. SQLite gets you publishing tonight on a laptop. MySQL keeps member tables, newsletter sends, and webhook volume stable when traffic grows.

Ghost 5.0 made the line clearer by documenting MySQL 8 as the production standard and de-emphasizing SQLite beyond development.

Why Ghost ships with SQLite at all

SQLite is a single file in content/data/. No separate database server to install, secure, or back up independently. For local theme development, staging proofs of concept, and solo blogs with modest traffic, SQLite is ideal.

That convenience is the point. SQLite removes friction from trying Ghost.

Where SQLite breaks down

SQLite uses file-level locking. Under concurrent writes—member signups during a newsletter blast, webhook retries, admin edits during imports—contention shows up as slow responses or lock timeouts.

Signals it is time to switch:

• Thousands of members with active email engagement
• Multiple staff editing simultaneously in admin
• Heavy integrations writing webhooks or API traffic constantly
• Production SLA requirements (managed backups and replication)

If you run a membership business on Ghost, plan for MySQL early.

Why MySQL 8 became the production default

Ghost 5.0 aligned documentation with what large publishers already ran: MySQL 8 on Ubuntu with Node 16. The member graph, email queue, and analytics-style tables benefit from a server database tuned for concurrent connections.

MySQL also fits standard DevOps tooling—automated backups, point-in-time recovery, read replicas, monitoring.

Migration path: SQLite to MySQL

1. Provision MySQL 8 — Docker, managed RDS, or your host’s database offering
2. Configure production config with MySQL connection settings
3. Export content from SQLite via Ghost export JSON
4. Import into fresh MySQL-backed Ghost on staging
5. Re-test memberships, Stripe, and email before cutover
6. Point DNS only after verified rebuild

Always migrate on a staging clone first. Member and Stripe IDs are unforgiving of half-finished moves.

When to stay on SQLite longer

SQLite remains valid for local theme work, low traffic, solo editorial teams, or evaluating Ghost before committing infrastructure budget. Do not stay on SQLite because migration feels scary—stay because your load genuinely fits.

Hybrid mental model

Many teams run SQLite locally, MySQL in production. Keep environment configs separate; never copy the SQLite file to production and call it done.

Checklist before you switch

• MySQL 8 instance sized for expected member/email volume
• Backup of SQLite database and Ghost content/ directory
• Staging migration tested end-to-end
• Stripe and email DNS verified post-migration
• Theme and integrations smoke-tested under MySQL load

For the release that codified MySQL 8 as production standard, see the Ghost 5.0 release guide.

Sources and further reading

• Ghost 5.0 release guide
• Ghost configuration documentation
• Ghost Developer Docs — Changes