I get asked about "sharding the Acumatica database" roughly once a year, usually by an engineer who has worked on a horizontally-scaled web application before and is applying that instinct to an ERP for the first time. The honest answer up front: Acumatica does not support arbitrary horizontal database sharding, and there is no supported configuration where you split one company's transactional data across multiple independent SQL Server databases and have the application transparently query across them. If that is what "sharding" means in your requirement, it is not on the table — and understanding why saves a lot of wasted design time.
Why this is not a knob you can turn
Acumatica's data access layer (BQL, PXCache, the graph model) assumes a single connection string per site and issues queries against one logical database. Multi-tenancy in Acumatica is handled by CompanyID discrimination within a single database (or, for the more isolated model, separate databases per tenant — see below), not by splitting one tenant's data by a shard key like customer ID or region across multiple databases the way you would shard a multi-tenant SaaS application's Postgres cluster. There is no framework-level query router that would let a BQL Select against ARInvoice transparently fan out across shards and merge results — every join, every report, every GI assumes everything it needs is reachable in one query against one database.
What Acumatica actually gives you instead
The real scaling levers, in the order I reach for them for a genuinely large instance:
- Read replicas via SQL Server Always On availability groups. Route reporting and read-heavy GI/report workloads to a readable secondary replica, keeping the primary free for transactional writes. This is a supported, well-trodden pattern for private-cloud and on-prem Acumatica and is the closest thing to "scaling out" that exists for read-heavy load.
- Vertical scaling of the database tier. More cores, more memory (for buffer pool), faster storage. SQL Server scales vertically very well, and for most Acumatica instances — even large ones — a properly sized single database server handles the transactional workload without needing to be split at all.
- Separate databases per company/tenant (as opposed to sharding one tenant's data). If you are running Acumatica for genuinely separate businesses or entities, Acumatica supports multiple companies within one tenant database, or fully separate tenant databases per client on a multi-tenant SaaS-style deployment — this is tenant isolation, not sharding a single tenant's dataset for scale.
- Archiving cold data out of the hot tables. Acumatica supports data retention/archival policies that move old transactional data out of the primary working set, which is often what people actually want when they say "sharding" — keeping the actively-queried tables smaller, not spreading live data across multiple databases.
I have seen a client's previous vendor attempt custom sharding by standing up per-region SQL Server databases and writing custom integration code to replicate reference data and reconcile transactional data between them. It technically ran, but every report that needed cross-region visibility became a custom ETL job, every upgrade had to be applied N times and verified for consistency N times, and reconciliation drift became a permanent, ongoing support burden. This is not a "advanced but supported" configuration — it is bespoke infrastructure sitting underneath a platform that has no awareness it exists, and the platform's upgrade and support model assumes it does not.
What the requirement usually actually is
When a client asks for "sharding," in my experience the underlying need is almost always one of: reporting queries are slowing down transactional users (answer: read replica), the database is getting large and old data is rarely queried (answer: archiving), or they are anticipating multi-region latency for a globally distributed user base (answer: regional app servers talking to one well-placed database, or genuinely separate regional tenant deployments if the businesses are actually separate). Naming the real requirement usually replaces "let's shard the database" with a much smaller, supported project.
Wrapping up
Acumatica does not natively support horizontal sharding of a single tenant's database, and building it yourself means owning a permanent, unsupported reconciliation and upgrade burden outside the platform's model. Reach for read replicas, vertical scaling, tenant-level database separation, and data archival instead — they cover the actual scaling needs that "sharding" requests are almost always describing.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.