Is SQLite per tenant safe for production WordPress?

Yes, for the right workloads. SQLite per tenant gives complete data isolation because each tenant lives in its own database file, with no server to provision. It suits smaller, low-concurrency tenants and easy portability. For higher-traffic, write-heavy tenants, a dedicated MySQL database handles concurrent writes and standard tooling better. GrabWP Tenancy Pro supports both, so you can match the engine to the tenant.

Can I move a tenant from SQLite to MySQL later?

Yes. GrabWP Tenancy Pro supports cross-database migration, letting you restore a tenant across engine types between shared MySQL, dedicated MySQL, and SQLite. You are not locked into your first choice, so you can start a tenant on SQLite and move it to a dedicated MySQL database when its traffic grows.

What isolation does a shared table prefix actually give?

A shared MySQL database with unique table prefixes keeps each tenant's tables logically separate inside one database, which is the lowest-overhead option but the weakest isolation. A dedicated MySQL database or a SQLite file per tenant gives complete data isolation with zero cross-tenant risk. The free GrabWP Tenancy plugin ships shared-prefix isolation; dedicated MySQL and SQLite are Pro features.

Dedicated MySQL vs SQLite per Tenant: Choosing WordPress Tenant Database Isolation

Choosing how to isolate each tenant’s data is the most consequential decision in a multi-tenant WordPress build. It sets the ceiling on isolation strength, the floor on operational overhead, and how easily you can move a tenant later. GrabWP Tenancy Pro gives you three per-tenant database options, and the right answer depends on the tenant, not on dogma. This guide walks through what each option isolates, when to reach for it, and why you are never locked into your first pick.

The Three Options and What Isolation Each Gives

Choosing SQLite, dedicated MySQL, or shared prefix per tenant in GrabWP Tenancy Pro

GrabWP Tenancy Pro supports three ways to store a tenant’s data, in ascending order of isolation strength.

Shared MySQL with unique table prefixes. Every tenant lives in the same MySQL database, separated by a unique table prefix. Tenant A’s tables and Tenant B’s tables sit side by side, distinguished only by their names. This is partial isolation: the data is logically separated but physically colocated, sharing one database, one connection pool, and one blast radius. It is the lowest-overhead option and the only isolation mode in the free GrabWP Tenancy plugin (paired with isolated uploads).

Dedicated MySQL database per tenant. Each tenant gets its own MySQL database. This is complete data isolation with zero cross-tenant risk: a query in one tenant cannot reach another tenant’s tables because they are in separate databases, often with separate credentials. You keep the full MySQL feature set, including standard backup, replication, and monitoring tooling.

SQLite database per tenant. Each tenant’s data lives in its own SQLite file. This is also complete data isolation with zero cross-tenant risk, but with no database server to provision at all. The SQLite integration library is bundled inside Pro, so there is no separate plugin to install, and the Isolated SQLite option is always available. Filenames are hashed per tenant for security and compatibility, and SQLite error handling suppresses verbose HTML errors while logging failed queries.

The headline: dedicated MySQL and SQLite both deliver complete isolation. Shared-prefix trades isolation for the lowest overhead. Your real choice, most of the time, is between the two complete-isolation engines.

When SQLite per Tenant Is the Right Call

SQLite is the simplest option, full stop. There is no database server to install, secure, tune, or keep running. A tenant is a single file, which makes provisioning nearly instant and portability trivial: copying, cloning, or archiving a tenant is a file operation, not a database dump-and-restore dance. Tenant cloning works with SQLite sources, so spinning up a new tenant from an existing one stays fast and self-contained.

Reach for SQLite per tenant when:

Tenants are smaller or low-concurrency. SQLite excels when writes are not heavily concurrent. For brochure sites, client microsites, portfolios, and low-traffic tenants, it is more than enough.
Portability matters. A single hashed file per tenant is easy to move between servers, snapshot, or hand off. No server-side database state travels with it.
You want minimal provisioning. No MySQL user, no database creation step, no connection credentials to manage per tenant. The engine is bundled inside Pro and ready to use.

SQLite is the pragmatic default for fleets of many small tenants where operational simplicity and per-tenant portability outweigh raw concurrent-write throughput.

When Dedicated MySQL Wins

Dedicated MySQL is the strongest choice for tenants that push traffic and writes. MySQL is built for concurrent connections and concurrent writes, so a tenant with heavy commenting, WooCommerce checkout activity, frequent publishing, or many simultaneous logged-in users belongs on its own MySQL database rather than a single file.

Choose dedicated MySQL per tenant when:

The tenant is write-heavy or higher-traffic. Concurrent writers are exactly where a real database server earns its keep. SQLite serializes writes; MySQL does not.
You depend on standard tooling. Point-in-time backups, replication, read replicas, slow-query logs, and the entire ecosystem of MySQL monitoring and administration tools work out of the box. If your ops team already runs MySQL, a dedicated database per tenant fits their existing runbooks.
You need per-tenant credentials and quotas. Separate databases make it straightforward to scope access and reason about each tenant in isolation at the server level.

You still get complete data isolation, the same as SQLite, but with the throughput headroom and operational maturity of a full database server. The cost is provisioning: each tenant needs a database and, typically, credentials.

When Shared-Prefix Is Acceptable

Shared-prefix isolation is not wrong, it is a deliberate trade. It gives you the lowest overhead of any option: one database, one connection, no per-tenant provisioning beyond a prefix. That is genuinely valuable in the right context.

Shared-prefix is acceptable when:

Tenants are low-risk and trusted. Internal sites, staging environments, or tenants under a single owner where the strict legal or security boundary between them is soft.
You are optimizing for density and simplicity. Packing many tiny tenants into one database keeps the footprint small and the setup minimal.
You are on the free plugin. The base GrabWP Tenancy plugin ships shared-prefix plus isolated uploads, which is a fine starting point to validate a multi-tenant model before upgrading.

Be honest about what it is: partial isolation. The data is logically separated but physically shares a database, so it does not carry the zero cross-tenant risk of a dedicated database or SQLite file. If tenants are independent customers with real isolation requirements, move up to a complete-isolation engine.

You Are Not Locked In: Cross-Database Migration

The most freeing fact in this whole decision: your first choice is not permanent. GrabWP Tenancy Pro supports cross-database migration, letting you restore a tenant across engine types. You can move a tenant between shared MySQL, dedicated MySQL, and SQLite in any direction.

That changes the stakes of the decision entirely. Start a new tenant on SQLite for simplicity, and when its traffic and write volume grow, migrate it to a dedicated MySQL database. Consolidate a set of quiet dedicated databases back down to SQLite files to reduce operational surface. Promote a shared-prefix tenant to complete isolation once it graduates from trial to production. Because migration is a restore across engines, you are choosing a starting point, not a life sentence.

Pair this with tenant backups and cloning, and each tenant becomes a portable unit you can move, snapshot, and re-home as its needs change. For the backup side of this workflow, see our tenant backup strategy for multi-tenant WordPress, and for the broader isolation model without Multisite, see how to isolate WordPress client sites without Multisite.

A Decision Framework

Work down this short list and stop at the first match:

Do the tenants need complete isolation with zero cross-tenant risk? If no (internal, trusted, or low-risk), shared-prefix is acceptable and cheapest. If yes, continue.
Is the tenant write-heavy or higher-traffic, or does your ops depend on MySQL tooling? If yes, use a dedicated MySQL database per tenant. Concurrent writes and standard tooling are where it wins.
Is the tenant smaller, low-concurrency, and are simplicity and portability the priority? If yes, use SQLite per tenant. No server to provision, one hashed file per tenant, easy to move and clone.
Unsure, or expecting the tenant to grow? Start on SQLite for simplicity and migrate to dedicated MySQL later. Cross-database migration means the choice is reversible.

A practical pattern for a mixed fleet: SQLite by default for the long tail of small tenants, dedicated MySQL for the handful of heavy hitters, shared-prefix only for trusted internal sites. Because you can migrate between engines, you can let each tenant start simple and earn its way onto a heavier engine when the load justifies it.

Get Started

The free GrabWP Tenancy plugin gives you shared-prefix isolation and isolated uploads to validate your multi-tenant setup. When you need complete per-tenant isolation, dedicated MySQL or SQLite engines, and cross-database migration, GrabWP Tenancy Pro unlocks all three database options for $9.99/month. Match the engine to the tenant, and move tenants between engines whenever their needs change.