Small and medium business | Business Central, N...

What are the real-world performance and scalability limitations of Dynamics 365 Business Central

(5) Share

Report

Posted on by talktoaliveallen

What are the real-world performance and scalability limitations of Dynamics 365 Business Central in high-transaction, multi-company environments?

We are evaluating Business Central for a fast-growing organization with multiple legal entities, complex intercompany processes, and heavy integrations (CRM, WMS, eCommerce, APIs).

From real production experience:

How does BC handle high transaction volumes and large datasets?
Are there known bottlenecks with posting routines, job queues, or intercompany?
How do custom extensions impact performance and upgrades?
At what point does BC become limiting compared to Dynamics 365 Finance, NetSuite, or SAP?

Looking for practical insights from consultants and partners — not marketing views.

Categories:

Dynamics 365 Business Central

I have the same question (0)

All responses (6)

Answers (0)

Suggested answer

Kamal Khakhkhar 1,500 on at

Like (1)

Report
Copy link

Link copied!

hii there ,
as business central is having almost all modules available in Basic , also you can able to customize as per your requirement . For intercompany , integration , scalable its one of the best fit for SMB small medium businesses.
for business central i had worked for that i had provided you limitations FYI.

as per requirement here i shared some of operational limit provided by Microsoft.

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/operational-limits-online

If You found answer mark it answered.

Thank You .

Kamal Khakhkhar.

Was this reply helpful? Yes No
TAHER Mehdi 338 on at

Like (0)

Report
Copy link

Link copied!

BC runs on Microsoft’s cloud infrastructure, which provides automatic scaling, load balancing, and performance monitoring. also supports multiple legal entities in one environment with built-in intercompany features. and if Extensions built using AL and following Microsoft’s best practices gonna be cloud-ready and easy for upgrade-safe. and integrations with (CRM, WMS, eCommerce, APIs) are common in projects. BC can scale impressively and remain cost-effective.

Was this reply helpful? Yes No
Greg Kujawa 639 on at

Like (1)

Report
Copy link

Link copied!
How does BC handle high transaction volumes and large datasets?

Are there known bottlenecks with posting routines, job queues, or intercompany?

How do custom extensions impact performance and upgrades?

At what point does BC become limiting compared to Dynamics 365 Finance, NetSuite, or SAP?

Our retail organization has five locations and around 120 users. We have intercompany as well. We have had a good overall experience leveraging BC 365 SaaS. BC is very extensible and allows for a lot of custom flexibility. What's nice is that when Microsoft releases new BC versions, any potential breaking changes in custom and third-party extensions are proactively notified to the tenant admin. Down to even identifying the AL source file and offending lines. Another plus is there is a rich ecosystem of ISV's that can add a lot of power and functionality to base BC.

One claim about Microsoft's cloud solutions offering automatic scaling and load balancing I would take with a grain of salt. After being on M365 as a whole since 2016, and being on BC 365 since 2023, I have found there are occasional cases where there are notable lags in their infrastructure. As an example, if you change a user's M365 security group on the Entra end, then that should sync up in BC 365 within a few minutes. We have had cases where that sync can take many hours before it completes. Even until the following day. Same with another example of adding a BC 365 user license in Entra, where it can lag reflecting in BC 365. When we've raised support tickets with Microsoft, the consensus each time is there is a backlog of customer transactions queued up. So you can infer that tenants share the same physical/virtual hardware and other resources. The knock-on effect of that is if one customer is processing a large "job" the other customer tenants will be sitting in queue.

Handling high transaction volumes and the like shouldn't be a problem. Microsoft publishes their operational limits, and they are definitely acceptable. One thing I would caution involves potential concurrency. Just recently we ran into cases where transaction posting would occasionally fail to completely hit the various sub-ledgers entirely. Without firing off any sort of runtime error or user notification. The cases were narrowed down to more than one user posting something pretty much simultaneously. The post is here.

Best of luck vetting BC as a potential solution. I would personally recommend it. Based on years of searching for the best fit for our organization's needs.

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Assisted by AI

OussamaSabbouh 6,871 on at

Like (1)

Report
Copy link

Link copied!

Hello ,

From real-world use, Business Central scales well for mid-market, multi-company environments, but its limits show up with very high posting volumes, heavy intercompany traffic, and chatty integrations. The main bottlenecks are posting routines (shared tables cause contention), job queues that don’t parallelize well, and integration design (many small API calls hurt more than users do). Performance issues usually come from custom extensions in posting or list pages and missing indexes, not BC itself. BC starts to feel limiting compared to D365 Finance or SAP when you need very high transaction throughput, 24/7 operations with strict SLAs, complex global finance, or deep high-volume warehousing. With good integration design, lean extensions, and data discipline, BC handles fast growth—but it’s not a tier-1 ERP replacement.

Regards,

Oussama Sabbouh

Was this reply helpful? Yes No
Suggested answer

YUN ZHU 95,985 Super User 2025 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi, Just adding some information.
Below is information Microsoft released in 2022; each version currently has performance optimizations, and these are not the upper limit.

Thanks

ZHU

Was this reply helpful? Yes No
Greg Kujawa 639 on at

Like (0)

Report
Copy link

Link copied!

The one point I brought up, which to me at least seems like kinda a big deal, is something that I am surprised hasn't gotten more feedback. That is up in this thread where I linked another Community post I made.

Concurrency is a very basic convention when it comes to any back-end DB. That one use case I provide is valid. Specifically, this is when customer payments against sales invoices are being posted. If we have two different users posting payments for two different customers right alongside one another, IMO if there are any sorts of SQL locking encountered then one of the users denied access to one of the resources due to SQL locks should receive a runtime error. Essentially informing them their transaction has failed and should be retried. But this isn't happening.

What we discovered is that both of these transactions complete without any sort of runtime error being raised. But the application of payment to document (and vice-versa) fails to complete per the detailed customer ledger entries. So their payment isn't being properly applied. Again, this is base BC. No ISV or custom extensions coming into play. It's 100% a concurrency issue. Apparently BC isn't engineered to handle basic SQL Server BEGIN TRANSACTION / COMMIT TRANSACTION logic, to rollback the one blocked user behind the scenes. And bubble that up to the user.

These are very, very basic SQL conventions when it comes to a multi-step process. Such as this case where we are posting to the customer sub-ledgers and then posting to the GL.

Was this reply helpful? Yes No