Workbook-Resident Storage
Every governed plan record persists as rows in native Excel ListObject tables inside the workbook file — no separate database, no background service, no server-side data store.
The decision to store all governed plan data in native Excel ListObject tables rather than a separate database is the foundational architectural choice that defines ProjectXL's deployment model and analytical capabilities. It is not a limitation — it is a deliberate design that makes the product self-contained, portable, and analytically flexible in ways that server-dependent products cannot match.
What "Workbook-Resident" Means
Every record that ProjectXL maintains — schedule activities, network links, labor assignments, non-labor cost plans, actual cost records, rate stacks, baseline snapshot payloads — is stored as rows in named ListObject tables inside the workbook file. These are standard Excel structured tables, not proprietary binary storage or hidden worksheets. They are accessible to any Excel feature that can work with table data.
The workbook file is simultaneously the user interface (the Excel application rendering ProjectXL's task-pane UX), the computation surface (Excel's calculation engine evaluating formulas against plan data), and the authoritative data record (the tables that store the plan). This three-in-one architecture is why a plan is a file — everything needed to understand, analyze, and work with the plan is contained in the single .xlsm file.
Implications for Backup and Portability
Backing up a plan means copying the file. Archiving a plan means storing the file. Sharing a plan with a colleague means sending the file. There is no database connection string to update, no sync job to trigger, and no risk of the file being in a different state than the database. The file contains the complete plan, including the full snapshot archive, and can be moved to any Excel-capable workstation without any additional setup.