Choosing a Database for EDGEBIC: The IT Decision

Choosing a database for EDGEBIC is an IT decision that comes down to team size and data ownership: a single planner runs on the default local SQLite file with no server, and a team runs on Microsoft SQL Server that every installation points at, both fully supported and on-premise. In EDGEBIC by User Solutions the deeper technical comparison is covered in the database options for IT buyers; this post frames the decision from the deployment owner's seat: matching the engine to the team, deciding who owns backups, and keeping the move between them cheap. It names controls that live in Settings, never any internal path.

The database choice sits at the start of the administrator's journey. For the full reference, read the EDGEBIC admin guide. This post is the decision itself, made once, deliberately.

Two Databases, Not a Long Menu

For real use, EDGEBIC runs on two databases, and the IT decision is between them. A third option, an in-memory database, exists only for testing and demos, because nothing it holds is saved. And two more names, PostgreSQL and MySQL, appear in the provider list but are not yet available. So the choice is genuinely two: SQLite or SQL Server.

Both are fully supported and exercised by the same automated tests, so neither is a lesser tier. SQLite is the default: a single database file on the workstation, created automatically on first run, with no server to install and no database administrator required. SQL Server is the shared option: a database on your IT-managed server that every EDGEBIC installation connects to, so a whole team works against one live plan. The single-file default is the same engine and schema as the server option; it simply lives in one portable file.

That parity matters for the decision. Because the application behaves identically on either engine, the choice is not about capability. It is about how many people need one shared plan and who owns the infrastructure underneath it.

The Real Decision: Team Size and Ownership

Strip the decision to its core and two questions decide it.

How many people need the same live plan? One planner owning the schedule needs no server: SQLite puts the whole system in one file on their workstation, and they are scheduling in minutes. The moment a second and third person need to work against the same schedule at the same time, a shared server is what gives everyone one authoritative plan instead of separate files. The switch point is not a headcount threshold so much as the first time two people need to see the same plan live.

Who owns backups and the server? This is the ownership half of the decision, and it is where IT actually earns the call. On SQLite, the database file and its backup live on the workstation: a one-click export makes a timestamped copy, and responsibility sits with whoever runs that machine. On SQL Server, the database joins IT's standard backup rotation and its lifecycle is IT's to manage. Choosing SQL Server is choosing to bring the scheduling database into managed infrastructure, which is exactly right for a team and exactly overkill for a single planner.

On-Premise, Under Your Control

One property spans both databases and often decides the whole matter for an IT owner: EDGEBIC is an on-premise desktop application, and its data lives entirely on infrastructure you control. A local file on a workstation or your own SQL Server instance on your network, with no requirement to send scheduling data to an external service.

For manufacturers with contractual or defense-related data-handling obligations, that is frequently the deciding factor before team size even enters the conversation. The data does not leave your network unless you move it. For the shared deployment, Windows authentication ties access to the network identities IT already manages and stores no password at all; for SQL authentication, the stored password is encrypted on disk and tied to the Windows account that entered it. Prefer Windows authentication and the question of a stored credential never arises.

This is the point worth carrying into a policy review: the database model is on-premise by design, so a policy that keeps production data in-house is satisfied by the default, not by a special configuration.

Keep the Move Between Them Cheap

The best part of the decision is that it is not permanent. Because both engines behave identically, moving from SQLite to SQL Server later is a settings change plus a data migration, not a rewrite. On the DataSource tab in Settings, you choose SQL Server, enter the server and database name, pick the authentication mode, test the connection, and apply with a restart. The application builds the database schema on first connection.

Two facts shape the migration. First, the switch itself is short and reversible in the sense that you can test the connection before committing. Second, and this is the one to plan for, switching does not move data automatically: the old database keeps everything and the new one starts empty. So the data move is a deliberate step, either a restore through a path IT supports or a rebuild of master data through import masks, which is often the cleaner start for a production go-live. Take the one-click export backup the switch dialog offers before you apply.

Because the move is cheap, the IT decision now is really about the path, not a permanent commitment. Start a single planner on SQLite today, and decide who will own the SQL Server and its backups for when the team arrives, so that server is ready rather than a scramble.

A Worked Decision

Consider a twelve-person shop with one planner today and three expected within a year. The instinct might be to stand up SQL Server immediately so it is done. The better decision reads the two questions.

Today, one person owns the plan, so SQLite is right: the planner is productive in minutes, the database is one portable file, and there is no server for IT to maintain before anyone needs it. The IT decision to make now is not which database to run, but who will own the eventual SQL Server and its backup rotation, so that infrastructure exists when the team does.

When the second and third planners arrive, the switch is a settings change on the DataSource tab plus a re-import of clean master data into the fresh server database, done at a quiet moment with an export backup taken first. Nothing the planner learned changes, because the application is identical on both engines. The shop got a zero-friction start and a clean enterprise path, and IT owned the one decision that actually needed owning: the server and its backups, chosen deliberately rather than under pressure.

For the deeper technical comparison of the two engines, read database options for IT buyers; for the rollout that follows this decision, planning a multi-user rollout; and for the ongoing care once a database is chosen, keeping the EDGEBIC database healthy over time.