-
National Buildings Database – data engineering opportunity
National Buildings Database
Department for Business, Energy & Industrial Strategy
This is a contract for a research project to produce a national database of all buildings in the UK. This will involve using a data engineering methodology (piloted by a previously commissioned research project to be provided to the successful bidder) with targeted surveys across all sectors of the non-domestic building stock. A contractor will be procured to: – Apply the prescribed methodology to combine existing data on buildings and energy use; – Design and carry out targeted sector-specific surveys to fill gaps in existing data; – Combine the existing data and surveys to deliver a fully populated national buildings database; – Provide robust documentation, guidance and training on use of the database; – Develop a method for updating the database using underlying existing data; – Develop a method for generating synthetic samples from the database.
Location Any region
Value £2,600,000 to £2,880,000
Date notice published 5 June 2023, last edited 22 June 2023
Closing 21 July 2023, 2pm
Notice status Open
Procurement stage Opportunity
-
2 Replies
-
This information is outdated as the closing date for tendering has passed. You can find more recent information on the project using
salesforce data enrichment tools or by searching for “National Buildings Database UK” or contacting BEIS directly.
-
This sounds like a fairly large-scale data infrastructure project rather than a simple “database build”, especially because it combines multiple legacy datasets, active survey collection, and then long-term maintainability plus synthetic data generation.
The tricky part in projects like this is usually not the initial population of the database, but the data harmonisation layer. When you’re merging existing building registries with energy usage datasets and then layering in survey data, you almost always end up with inconsistent identifiers, missing fields, and different classification standards across sectors. That’s where a lot of the engineering effort tends to concentrate.
The requirement to maintain and continuously update the dataset also suggests this is meant to be a living system rather than a one-off research output. In that case, the update mechanism becomes just as important as the initial build — otherwise the dataset will degrade quickly after handover.
The synthetic sample generation part is interesting as well, because it usually implies either statistical modelling or some form of generative approach to preserve distributional properties while anonymising sensitive data. That also tends to introduce additional validation complexity, since stakeholders will expect synthetic outputs to remain consistent with real-world aggregates.
From a delivery perspective, projects like this also benefit heavily from clear documentation and reproducible pipelines, not just final datasets. In many cases, the “usability” of the system depends more on how well the process is packaged and communicated than on the raw data itself. This is often where structured documentation and proposal formats become useful — for example, teams sometimes use tools like integrate qwilr to present complex data engineering workflows in a way that non-technical stakeholders can actually evaluate and sign off on.
Log in to reply.