Capacity planning
User capacity limits and scaling paths for cloud-hosted Access systems.
One of the most common questions we hear from teams moving Access to the cloud is: how many users can it actually support? The answer depends entirely on your architecture , file-based back-end vs SQL vs web app , not on whether the server is local or in the cloud. This guide breaks down concurrency limits for each model, explains why cloud hosting alone does not solve multi-user problems, and helps you plan capacity before performance failures force an emergency migration.
Microsoft Access was designed as a desktop database for small workgroups. The Jet/ACE engine that powers .accdb files uses file-level and record-level locking optimized for 5–10 simultaneous users on a fast local network. Moving that same file to a cloud server does not change the engine , it only changes where the file lives.
This distinction matters because many teams expect cloud hosting to magically solve the multi-user problems they experienced on a network share. Cloud hosting solves remote access, backup, and infrastructure reliability. It does not rewrite the ACE engine's concurrency model. To support more users, you must change the architecture , not just the hosting location.
Three variables determine your practical user capacity: back-end type (file vs SQL vs web API), write intensity (read-heavy browsing vs constant data entry), and application design (indexed queries and split database vs unindexed tables loaded entirely into memory). The sections below quantify capacity for each architecture.
When your Access back-end is an .accdb file , whether on a local server, network share, or cloud VM disk , the Jet/ACE engine manages all locking at the file level. This is the most common configuration for legacy Access systems and the most limited for multi-user cloud deployment.
The ACE engine locks pages (4 KB blocks) within the .accdb file during write operations. When two users attempt to write to records on the same page simultaneously, one must wait , or receive a lock conflict error after a timeout. On a cloud-hosted VM, network latency between the Access front-end and the back-end file adds delay to every lock acquisition, effectively reducing capacity compared to a local network.
| Architecture | Concurrent users (write-heavy) | Concurrent users (read-heavy) | Database size limit |
|---|---|---|---|
| File BE on network share | 3–8 | 8–12 | 2 GB |
| File BE on cloud VM (local disk) | 5–10 | 10–15 | 2 GB |
| SQL BE + Access front-end (hosted) | 15–30 | 30–50 | SQL engine limit |
| SQL BE + Access front-end (local + VPN) | 10–20 | 20–35 | SQL engine limit |
| Web app + SQL back-end | 50–200+ | 200–500+ | SQL engine limit |
Hosted desktop , running Access on a cloud Windows server accessed via Remote Desktop , is the most popular cloud deployment model. Its user capacity depends on two factors: how many simultaneous RDP sessions the VM supports, and how many concurrent database writers the back-end architecture allows.
Session capacity is rarely the bottleneck. Database locking is. A t3.xlarge can host 15 RDP sessions, but if all 15 users write to a file-based back-end simultaneously, lock conflicts will make the system unusable before CPU or memory max out.
For managed hosting that handles VM sizing and front-end deployment, see host MS Access online.
Hitting user limits on your cloud-hosted Access database?
Request a capacity assessmentMoving your Access back-end from an .accdb file to SQL Server, Azure SQL, or PostgreSQL is the single highest-impact change for multi-user capacity. SQL engines handle row-level locking, connection pooling, and concurrent transactions natively , capabilities the ACE file engine was never designed to provide.
After SQL upsizing, 15–30 concurrent writers is typical for well-designed Access front-ends linked to SQL Server. With query optimization and pass-through queries, 30–50 concurrent users is achievable. Beyond 50 users, the Access front-end becomes the bottleneck , forms load slowly over ODBC, VBA operations block the UI, and deployment management grows complex. Web app conversion is recommended at that scale.
Review Access database online options for SQL upsizing as part of a cloud hosting engagement.
A web application backed by SQL Server or PostgreSQL removes the Access front-end from the concurrency equation entirely. Users interact through a browser; the server handles all data access through connection-pooled API calls with proper transaction management.
Web apps scale further because there is no file locking, connection pooling reuses database connections efficiently, each request is stateless, and you can add web server instances behind a load balancer as user count grows. Typical deployments support 50–200 concurrent users on a modest setup, and 500+ with appropriate scaling.
Learn about the conversion process on our MS Access to web app page. Compare investment levels at modernization pricing.
Use this planning matrix to choose the right architecture based on your current and projected user counts:
Cloud desktop with file-based back-end is viable if the database is split, indexed, and under 1 GB. Monitor lock conflict frequency monthly. Plan SQL upsizing when you approach 8 concurrent writers or 1.5 GB file size.
Cloud desktop with SQL back-end is the minimum recommended architecture. File-based back-ends at this scale generate daily operational friction. Budget for SQL migration as part of your hosting project, not as a future phase.
SQL back-end with hosted Access front-end works as a bridge, but begin web app conversion planning immediately. Target web app go-live within 12–18 months.
Start web app conversion now. Hosted Access at this scale costs more in per-user RDP fees, support overhead, and operational risk than a phased web migration.
For remote access context that affects perceived performance at scale, see Access remote access options.
Not sure how many users your Access architecture can support?
Book a free capacity planning sessionRelated reads: Access database online · Host MS Access online · Remote access without VPN · Modernization pricing · Access to web app
For multi-user cloud hosting options, see our Access Database Online.
With a file-based back-end on a network share or hosted desktop, plan for 5–10 concurrent users for write-heavy workflows and up to 15 for read-heavy use. With a SQL Server or PostgreSQL back-end, 20–50 concurrent users is realistic. A web app supports 50–500+ depending on architecture.
Cloud hosting improves reliability and remote access but does not change the Jet/ACE engine's concurrency limits on file-based back-ends. Moving to the cloud helps only when you also move the back-end to SQL or convert to a web app.
File-level locking, network latency to the back-end file, unindexed fields in frequently queried tables, forms that load entire tables instead of filtered subsets, and VBA code that holds locks open during long operations.
When you consistently exceed 15 concurrent writers on a file back-end, when lock conflict errors appear daily, or when onboarding new users requires more than adding an RDP account. These are signals the architecture , not the hosting , is the bottleneck.
Technically yes, but it fragments data, complicates reporting, and creates referential integrity problems. Upsizing to a single SQL back-end or converting to a web app is almost always the better path when user count outgrows a single file.
Simulate peak load: have 2–3 testers perform write-heavy operations simultaneously while others run reports and browse records. Monitor for lock errors, save failures, and response times above 3 seconds on common forms. Repeat at each increment until failures appear.