Capacity and sizing

How many people an Archestack instance serves at once, which servers it needs for that, and how many workspaces one database server holds. Every figure on this page was measured in load tests on 23 September 2026, with simulated people signing in and working through the app. None of it is projected: a larger install is sized in whole blocks of a tested size.

At a glance

All of these are with live updates turned off. With them on, which is the default, one workspace is comfortable up to about 100 people at once.

How the tests work

• People. Each simulated person signs in with their own account and works through lists, records, searches, saves and a dashboard, pausing 6 seconds between clicks on average. A quarter of them use the builder, the rest the published app. "People at once" counts people clicking at the same time, not accounts.
• Steps. People are added over 45 seconds and then held for 3 minutes. Every figure comes from those steady 3 minutes.
• Fast. A step counts as fast when 95% of page loads finish within 1 second and fewer than 1% of requests fail. A page load runs from the click to the last piece of data on the page.
• Machine. One desktop PC with an Intel Core i9-12900KF and 96 GB of memory. Each server ran in a container with processor cores of its own, and the load generator had cores of its own too. PostgreSQL 16, PgBouncer 1.25 where it was used, rate limits on.

One workspace, many people

One company with everyone in the same workspace, holding 2,500 customers, 25,000 orders and 75,000 order lines, on a 4 core application server and a 2 core database server:

Above 1,000 people the load generator ran out of processor, so the limit of one workspace was not found. At 1,000, neither server was using a whole core.

Live updates

By default, every saved row is pushed to every open screen that shows it, and each of those screens reloads its record, its related lists and their labels. That cost grows with the square of the number of people in a workspace. On the same build and the same servers, about 100 people at once were comfortable with live updates on, against 1,000 with them off; at 200 people, 86% of all requests were those reloads.

Turn them off with Realtime__EntityChanges=false on the application server. Open screens then show a colleague's change the next time they load. Saving, searching, notifications and who else is on a page work as before. Every other figure on this page is with live updates off.

Many companies on one instance

Companies of 100 people each, every company a workspace with its own copy of the app (500 customers, 5,000 orders and 15,000 order lines), on two server sizes:

The first figure of each pair is the application server, the second the database server. As a rule of thumb, 1,000 people at once use about half an application core and half a database core.

Where one database server runs out

Connecting directly, every workspace keeps connection pools of its own, and they grow with the load. At 5,000 people the 4 + 4 database server reached almost 2,000 connections and page loads collapsed; a 6 + 6 pair never settled at all. Through PgBouncer in transaction mode, the workspaces' databases share pools of a few connections each: the 4 + 4 pair then served 4,000 people with 95% of pages within 54 ms on 400 connections, and an 8 + 8 pair held 8,000 people on 757. That 8 + 8 run shared the PC's cores with the load generator, so it shows connections only and is not used for sizing.

Servers for more people

A block is the tested pair: a 4 core application server and a 4 core database server with PgBouncer, counted at 4,000 people so it keeps some headroom. A larger install adds whole blocks.

Today each block is a deployment of its own, and a company lives on one block. Spreading companies over several blocks behind one address and one sign-in is not built yet.

Many workspaces on one database server

A separate test kept adding workspaces to one database server, with 50 of them in use at any moment, up to 5,000 workspaces:

• No failures. 5,000 workspaces without a failed signup or a failed request.
• Idle costs nothing. A workspace nobody uses holds no database connection. After six minutes without use, all 5,000 held 3 connections between them.
• A new workspace in about a second. 0.9 seconds median, both databases created and prepared.
• About 18 MB of disk per workspace: two databases and a small app, before your own data.

The connections held stay flat however many workspaces there are, because only the ones in use hold any. Two things do grow with the number of workspaces: the application server's memory, and the time a restart takes until the API answers again, which reached almost four minutes at 5,000 workspaces. Plan restarts of a large instance accordingly.

Settings behind these numbers

• Live updates off: Realtime__EntityChanges=false on the application server, see above.
• Database shared memory: shm_size: 1g on the PostgreSQL container. PostgreSQL keeps statistics for every database in shared memory, about 55 KB each, and Docker gives a container 64 MB unless told otherwise. 1 GB covers some 9,000 workspaces.
• Connection pooling: PgBouncer in transaction mode, with a wildcard database entry so a new workspace needs no configuration, 2 connections per database with 1 in reserve, and a ceiling on server connections of at least 4 per busy company and below PostgreSQL's max_connections. A tighter ceiling makes PgBouncer close one company's connections to open another's: 400 connections for 150 companies saturated both servers with that churn. The application server's connection strings carry No Reset On Close=true. Third-party data sync uses temporary tables, which transaction pooling does not keep, so it still needs a direct connection.
• Database maintenance: with thousands of databases, a longer autovacuum_naptime spreads PostgreSQL's own visits to every database.

What the numbers do not cover

• Cloud processors. A cloud virtual processor is usually slower than a core of this desktop processor.
• The network and the browser. Page times exclude the network between the servers and your users, and the time the browser takes to draw the page.
• Heavier apps. Pages with more related lists, or larger tables, cost more per page than the test app's.
• Past 10,000 people. Nothing here is extrapolated beyond a tested size.

Where this goes next

Workspaces and hosting explains the choice between one workspace per instance and several, and the two ways to run the containers.