Planning EDGEBIC Hardware and Sizing

EDGEBIC runs as a Windows desktop application, so a single-user pilot needs only a standard Windows workstation and the local single-file database, while a team adds a shared SQL Server database on an IT-managed server, sized as a typical business database. In EDGEBIC by User Solutions you size by how you deploy, not by a heavy up-front spec. The scheduling work happens on the desktop, so the hardware conversation is refreshingly modest at every stage.

This post is the sizing conversation for an administrator or IT partner. For the full reference behind the deployment choices here, read the EDGEBIC admin guide, and for the database decision itself, see choosing a database for EDGEBIC. It describes deployment at the level of workstation versus shared server, never any internal path.

The Pilot: One Workstation, No Server

The smallest EDGEBIC deployment is also the most common starting point, and it needs almost nothing. EDGEBIC is a Windows desktop application, and its default database is a single portable file that lives on the same machine. So a single-user pilot is a standard Windows workstation and nothing else. There is no server to provision, no database to stand up, and no IT project to schedule before a planner can begin.

This is why a pilot can start the same day the decision is made. The planner installs the application, the local database comes with it, and the pilot is running. The data is protected with the one-click export backup from the DataSource tab, so even the smallest deployment has a real backup path. The whole point of the local single-file model is that evaluating EDGEBIC costs a workstation, not a capital request.

The Team: Add a Shared Database

When a pilot proves out and more than one person needs to plan against the same data, the deployment grows in exactly one dimension: a shared SQL Server database on a server that IT manages. What does not change is where the application runs. Each planner still runs the desktop application on their own workstation. Only the database moves from a local file to a shared server so everyone works against one source of truth.

This shape (desktop clients, shared database) is the standard business-application pattern, and it means the server sizing is a database conversation, not a compute conversation. The scheduling engine runs in each planner's desktop, so the server is not doing heavy calculation. It is holding the data and serving it to a handful of clients, which is a modest load by any database standard. The move itself is covered in moving from single user to a shared server.

Sizing the Shared Server

Because the shared server is a typical business database rather than a compute host, sizing follows IT's normal standards for a small-to-midsize database. A team of ten planners is ten desktop clients reading and writing to one database, which is a light load. The questions that actually matter are not about raw size.

Notice that none of these is a specification like a core count. The right frame is "a reliable, backed-up, reachable database server that meets your normal standards," because that is what a scheduling team needs from it. Over-specifying a heavy compute server would spend money the desktop-side engine does not require.

Start Small, Grow Deliberately

The sizing story reduces to a simple progression. Pilot on a single workstation with the local database, because it costs nothing to try and protects its data with one click. When the plant is ready for a team, add a shared SQL Server database that meets IT's ordinary reliability and backup standards, and keep every planner on their own workstation. The shared server is sized as a typical business database, not a heavy host, because the scheduling calculation lives on the desktop.

That progression lets a plant prove value before spending on infrastructure, and it keeps the eventual infrastructure ask modest and familiar to IT. For the multi-user planning that follows the hardware decision, read planning a multi-user EDGEBIC rollout, and for the general context of what the software does with the hardware, see finite versus infinite capacity scheduling. The full administrator reference is the EDGEBIC admin guide.