Laboratory plans let a self-driving database prepare for the workload of a two-dimensional materials laboratory network

Self-driving laboratories for materials discovery store every crystal, image, flake and measurement in shared databases that instruments, scientists and agents wait on. These databases are configured once by developers, although a facility’s users change as it becomes a national service. Self-driving database management systems reconfigure themselves, but forecast future queries from past ones and so cannot anticipate users who have not yet arrived. We hypothesised that a database reading the laboratory network’s plan, its instrument scheduler and its calendar of approved proposals and workshops, would be ready for each workload change as it starts, unlike a tuner learning from history. We tested this with a copy of the production database of AURORA, a Programmable Cloud Laboratory node for two-dimensional quantum materials, under simulated laboratory events, user groups, language-model agents and a script surge, in 30 runs each. The plan-aware tuner had the indexes (lookup structures that spare a query from reading a whole table) for review and stacking ready 0.3 s after each laboratory event, against about 11 s when learning from history, and kept new user groups within their latency targets with 29 % less index space than the hand-set configuration. Agents spent 0.02–5 % of a 3–90 s decision in the database, depending on their model. Connection reservations set from the plan and recent arrivals kept scientists on target in surges of unknown size that no fixed split handled. A laboratory network’s announced work is therefore a usable workload forecast, letting a facility prepare its database before users arrive.