Newbie question: usage scenario

[TheDarkMist]

Hello LudicrousDB Community,
I am exploring the feasibility of implementing LudicrousDB for my WordPress site and would greatly appreciate your insights and suggestions.
My WordPress site is experiencing substantial database load challenges. The database has been optimized to the best of our abilities, yet it remains quite heavy and taxing on our system. The site is currently hosted on a server with cPanel, while we are considering utilizing Amazon RDS for our database needs.
Is this a good scenario for LudicrousDB? What is not clear to me is how the latency could affect, and possibly make worse, the site responsiveness.

Thank you in advance for your suport!

Francesco-

[ramonfincken]

Are you 100% sure it is not PHP that is causing load times ?

[TheDarkMist]

no 😄
But having custom post types with many custom fields and millions of records and enormous joins, I feel mySQL has some responsibilities...

[ramonfincken]

You need to make sure ( measure it with a profiler, APM, blackfire ) first.

[TheDarkMist]

Ok, thank you!

[JJJ]

LudicrousDB is useful when measurement shows that database reads, connection availability, or table placement are the bottleneck. It will not make a single overloaded database faster by itself; you need replicas or partitioned datasets behind it, plus a plan for replication lag and failure.

I would profile the slow requests first and separate PHP time, database time, query count, and individual slow queries. If the database is genuinely the constraint, an RDS primary with read replicas can be a reasonable LudicrousDB setup.

Latency absolutely matters. Keep the application and database in the same AWS region and, where possible, use nearby endpoints with private networking. Test representative page loads, administration, cron, checkout or other write-heavy paths, and read-after-write behavior from staging before moving production traffic. A remote database across regions or the public internet can easily make responsiveness worse even when the database itself is larger.

The short version is: profile first, fix expensive queries and missing indexes, then introduce LudicrousDB when there is a concrete read-scaling, failover, or partitioning job for it to do.