Large WordPress database

My database size is more than 10GB and it slow down the website. I want to split it and separate these DBs to dedicated servers. I'm using MariaDB.

How can I split the WordPress database?

Take a look at this answer on WPSE: https://wordpress.stackexchange.com/questions/2825/wordpress-sharding-which-multi-db-plugin-to-use

That said, a large database isn't inherently a bad thing. What is bad, however is an unoptimized database, a bloated database (many plugins just dump data around (often the postmeta or options tables), and unoptimized databse queries.

There's a few DB Optimizations plugins out there I'd look at using first, or just manually dig through it. Make sure your options table is as lean as possible, and make sure any and all orphaned data (for instance media images that no longer have a parent post and aren't referenced anywhere) is removed. I've seen plugins leave hundreds of megabytes worth of all but useless data inside the options table. And when that is loaded on every page request, the site grinds to a molasses-like state.

From a purely anecdotal perspective, I'm currently working on ground-up refactoring of a slow/bloated decade-old site. It used a ton of plugins, the database had tons of duplicate information across numerous tables, there were many meta queries (which are NOT indexed or keyed and are thus incredibly slow on large sites) and there were a ton of useless/outdated options stored in the options table.

The new site is filled to the brim with 100% viable test data, and the database is sitting roughly at 3 or 4 gigs right now. The thing is that my tables are optimized, columns are appropriately indexed, and I've even got custom relational post tables linking post types together. I've got about 450,000 posts of various post types in there, and using simple queries with the $wpdb class, it can sift and load dozens or hundreds of posts in fractions of a second without blowing up the memory usage.

The skinny is that you should almost certainly look at optimizing and trimming down your database before you consider splitting/sharding your database.

Another option would be to look at improving your hardware, namely having a host machine and a database machine which will inherently improve performance because each machine can be optimized for the task-at-hand and not share resources it doesn't need to.

Here's a simple screenshot of one of my requests. This is from a page loading 200 custom post types from the table with 450,000 records in it. Each custom post type is related to between 0-20 other post types, and one is even related to 1,500 others - and still it loads almost instantly despite not even being fully optimized yet.