Why I rolled back from 3.1.0 to 2.9.86 — with real numbers (and what support said)

Nikola Belopitov Thanks for sharing your experience here...However, my opinion is that as I didn't see in the post any mention of working with WPManageNinja support, I would recommend putting in a support ticket to help you diagnose the issue. It could be something simple. Just a thought.

I'm experiencing the exact same situation as you. In my case, I have even more senders and about 100,000 subscribers.

Previously, it took only three or four hours to finish sending, but now it's taking over 20 hours. This has also significantly slowed down the performance of my WordPress site.

I haven't been able to clearly document the specific data or reflect this status yet, but at this point, it looks like a rollback is the better option.

Do you guys use the v2.9.86 because it does not have the vulnerability of the v2.9.87?

I'm waiting to put V3 in production as I noticed in dev that a contact can now have multiple time the same tag and list shown in it's profile.

https://patchstack.com/database/wordpress/plugin/fluent-crm/vulnerability/wordpress-fluentcrm-email-newsletter-automation-email-marketing-email-campaigns-optins-leads-and-crm-solution-plugin-2-9-87-unauthenticated-blind-server-side-request-forgery-vulnerability

I've had to roll back from v3.x because all templates broke (in subtle but real ways) in v3.x, and rebuilding everything is not a job I can do right now. (already reported and documented to support)

I've also noticed a quite significant performance drop in the responsiveness itself when updating to 3.0, so I also rolled back.

Following up — a week later:

First, I want to genuinely acknowledge the scale of work the FluentCRM team has put into 3.x. The architectural ambition is real, and I have full respect for what Shahjahan Jewel  and the developers have built — FluentCRM has been an excellent product for our setup for years, which is exactly why I'm taking the time to write this.

That said, it's now been 7+ days since I posted these findings, and there's still no public technical response. Combined with similar reports from other users at scale — Waki Chuang 100k-subscriber site going from 3–4 hours to 20+ hours, @Lee Busch's template regressions, Mikkel Toftlund  admin performance drop, Angelo van der Klift  broken templates — this looks less like edge cases and more like a pattern worth structured attention.

What I'd genuinely appreciate hearing, even briefly:

1. Is the 2.x→3.x performance regression at production scale being actively investigated at the engineering level? Not asking for an ETA or a fix — just confirmation that it's on the radar would help all of us plan. Right now we're operating in uncertainty.

2. Would you consider a "stable" / LTS release channel alongside the cutting-edge 3.x line? Many of us run production-critical email infrastructure where stability matters more than new features. A channel that prioritizes reliability would let both audiences win — innovation continues on 3.x, while production users have a supported path that doesn't shift architecture under them.

I want to be clear: I'm not criticizing the direction of 3.x or the work being done. I'm asking for visibility into whether these regressions are being looked at, because right now, silence reads as uncertainty, and uncertainty makes production planning very hard.

I remain on 2.9.86 — works reliably, handles my volume, no regressions. Happy to keep sharing diagnostics (SQL, send-rate measurements, server load, cron logs) if it helps engineering pinpoint what changed in the 3.x sending path.

With continued respect for the team and the product.

I would support this @nikolabelopitov. It's as such a great direction 3.0 is heading in, but at the end of the day, the motor is what's powering the automobile, not the body work. Again, absolutely no criticism to the ninja team, I know they're working as hard as can to provide the best plugins in the WP community, and much appreciated! But an upgrade can never be UI only and deteriorating under the hood performance, it's as simple as that.

Shahjahan Jewel - What's the lag or reasoning for no response? This post interests me and I want to know if its still an issue, a one off problem that effects limited users or ?? and at the same time this is a red flag for 3.x, I just spent 2 day fine tuning and setting up FluentCRM 3.x for a new project with a small list of 7k subscribers, haven't sent yet, but will be extremely disappointed if the email send rates are slow as in above.

Please respond with current status, and if a fix is in place. This should be a top priority and it appears its being glossed over by support.

Thanks,
Jason

Campaigns section is extremely slow loading after upgrade to FluentCRM 3.x

I wanted to add our experience here because the lag/processing issue is not just a minor inconvenience for higher-volume senders — it can become a serious operational problem.

We recently attempted to send a campaign to approximately 146,000 contacts through FluentCRM, using SendGrid as the actual sending service. The campaign was intentionally throttled to go out slowly over the course of the day. The email itself contained roughly 24–50 links, which is not unusual for our use case and unfortunately cannot be reduced much.

As the day went on, the server became increasingly overloaded and eventually crashed. My assumption is that the issue was not SendGrid delivery itself, but the amount of processing FluentCRM/WordPress had to do: generating the individual emails, rewriting/tracking many links per recipient, processing the queue, and logging opens/clicks back into the database.

For smaller lists this may not show up as dramatically, but for businesses using FluentCRM at scale, processing speed and database load are critical. A campaign that technically “sends” but causes massive lag, delayed processing, or server instability is not viable for production use.

We moved from SendGrid Marketing Campaigns to FluentCRM specifically to manage our own contacts and avoid the high per-contact platform costs. FluentCRM is very appealing for that reason, and we want to continue using it. But the campaign processing performance needs to be reliable enough for larger lists, especially when link tracking is enabled.

It would be very helpful if the FluentCRM team could address this directly, including:

• Recommended server requirements for lists over 100k contacts
• Realistic send-rate guidance for high-volume campaigns
• Whether link tracking/open tracking significantly increases database load
• Whether campaign processing changed in recent versions
• Any known bottlenecks in queue processing, URL tracking, or click/open logging
• Whether there are planned optimizations for batch processing, database indexing, or background workers

This is not meant as criticism for the sake of criticism. We like FluentCRM and want it to work for our business. But the lag and processing load are serious enough that we need to understand whether FluentCRM is intended to support this kind of volume, and if so, what the optimal configuration should be.

Hi Nikola Belopitov and everyone aftected... I'm curious to know if any of you have tested the lastest version 3.1.5 and if it has improved the sending performance. Thanks!

Update — 3.1.7 is out, original questions still open.

First, sincere thanks to Shahjahan Jewel  and the team for shipping 3.1.5. I read the release notes carefully and I genuinely appreciate the work that went into the campaign queue improvements: lock-first sender handling, stale email recovery, loopback fallback, and the fix for recipient skipping on large sends. These are exactly the kind of refinements production users notice. The continued pace of work is impressive, and I want to acknowledge that openly.

That said — and I write this with full respect for the team's effort — the 3.1.5 release notes don't address the two specific concerns several of us raised here:

1. The 2.x → 3.x throughput regression itself. Not the queue reliability (which 3.1.5 improves), but the raw sending speed. On my setup, identical infrastructure produces ~3.5 emails/min on 3.x vs 39 minutes for 25k recipients on 2.9.86. The 3.0 marketing promised "up to 10X faster sending." My measurements — and Waki Chuang , and others in this thread — show the opposite at production scale. I haven't seen this addressed publicly, and 3.1.5 doesn't seem to claim it has been fixed either. So the question stands: is the throughput regression itself being investigated at the engineering level, or are queue reliability improvements considered the resolution? These are different problems.

2. A stable/LTS release channel for production-critical users. Still no public response to whether this is on the roadmap, and I think it deserves one. Many of us aren't asking for less innovation on 3.x — we're asking for a supported path that doesn't shift architecture under live mission-critical systems. The fact that several of us independently chose to stay on or roll back to 2.9.86, despite security and feature trade-offs, suggests this isn't a niche request.

I also want to address what I think is happening structurally, with as much fairness as I can:

The 3.x release cadence — 3.0 → 3.0.x → 3.1.0 → 3.1.5 in a matter of weeks — combined with new feature work (FluentCart subscription opt-in, AI integrations, WordPress 7 compatibility, FluentCart product blocks) makes me wonder whether the foundational sending pipeline is getting the same depth of engineering attention as the feature surface. I'm not in a position to claim that's what's happening. But from the outside, it's how it looks. And for those of us whose businesses depend on the sending engine, that's a meaningful signal.

To be very clear: I'm not criticizing the direction of 3.x as a product. The Vue 3 rebuild, the Gutenberg editor, the FluentCart integration — these are real, valuable improvements. The team's ambition is impressive. I genuinely want 3.x to succeed for everyone.

What I — and I think many others reading this — are asking for is simply visibility:

• Is the throughput regression a known issue being actively worked?
• Is there an ETA or even a quarter-level target for a version that restores 2.x-equivalent send rates?
• Is an LTS / stable channel under consideration?

Even a brief "yes, it's being investigated; no ETA" would be enormously helpful for production planning. The current silence on these specific questions is what makes it hard to recommend 3.x to peers right now.

JF  — to answer your question: I haven't upgraded to 3.1.5 yet, and I won't be testing it on production. After losing nearly a week of work to the 3.0.x troubleshooting cycle, I need a clear statement from engineering that the throughput regression is resolved before I'm willing to spend another production cycle on it. If anyone on a comparable setup (Cloudways/Kubernetes, ~25k+ list, Elastic Email or similar EU ESP) has tested 3.1.5 head-to-head against 2.9.86, I'd love to see real numbers.

Jason Janes — completely agree with your read. The lack of a clear technical statement is the red flag, more than the regression itself.

W Creative  Thomas Oates  — your reports (146k and 160k lists) reinforce that this isn't an edge case at our scale. The questions you're raising about server requirements, link tracking load, and queue bottlenecks are exactly the ones that need official answers.

Still on 2.9.86, still happy to share full diagnostics (SQL, send-rate measurements, server load, cron logs, cURL error patterns) if engineering wants to look at a concrete production case.

With continued respect for the team and the product.

Update for the thread:

Shahjahan Jewel  responded to Thomas Oates  in the 3.1.7 announcement thread: "we have improved a lot about the sending speed so you should use the latest version."

I appreciate the response. But I want to address something that's been concerning me throughout this entire situation:

Across three different channels — a support ticket I opened before starting this thread, a direct message I sent to Shahjahan Jewel  before starting this thread, and this thread itself (open for over a month, 24+ likes, multiple production users reporting similar regressions: Waki Chuang  at 100k, Lee Busch , Mikkel Toftlund , Angelo van der Klift , Jason Janes , W Creative  at 146k, Thomas Oates  at 160k) — I have not received a single direct response on the throughput question.

The only acknowledgment came when Thomas Oates  raised it publicly in a release announcement — and even then, the response was a one-line redirect to "use the latest version," delivered in a different thread.

That pattern — silence in private support, silence in DM, silence in a public thread with multiple affected users, but a brief redirect when raised in a release announcement — makes it very hard to interpret what's actually happening. Is the regression considered fixed? Is it being investigated? Is it acknowledged as a real issue at all? After more than a month and three channels, none of those questions has a clear answer.

That's not what I'd expect from a project that describes itself as community-driven and feedback-shaped.

To make this actionable, three specific questions remain open:

1. What specifically changed in the sending pipeline between 3.1.0 and 3.1.7? The 3.1.5 and 3.1.7 release notes mention queue reliability improvements (lock-first handling, stale recovery, loopback fallback), but not throughput.

2. Has the connection reuse issue been addressed? Specifically, the cURL error 28 pattern at high send rates that suggested a new HTTPS connection per email rather than reuse.

3. Real numbers? Has the team benchmarked 3.1.7 head-to-head against 2.9.86 at production scale (>20-30-100k+ recipients, EU SMTP)? "Improved a lot" is hard to act on without measurable comparison.

It's clear from this thread and others that experiences with 3.x vary significantly by setup — which is exactly why concrete technical details and benchmarks from the team would help all of us make informed decisions for our own infrastructure.

For those of us running production-critical email systems, "use the latest version" isn't a workable upgrade path without specifics. We've already been through 3.0 → 3.0.x → 3.1.0 → 3.1.5 → 3.1.7, each promising improvements. Without a clear technical statement on what was wrong and what was actually fixed, every upgrade is a roll of the dice on production infrastructure.

Staying on 2.9.86 — works reliably, handles my volume, no regressions.

Would genuinely appreciate hearing from anyone on the dev team in this thread, on the open ticket, or via the DM that's been sitting unanswered — even a one-line technical confirmation that the throughput regression has been measured and fixed would be enough to consider upgrading. That's a reasonable ask.

Thanks to Thomas Oates  for raising the question publicly.