“Behind the Meter” may mean “Front of the Line”

There is a tremendous amount of discussion about "behind the meter" as well as "energy storage" and other power concepts in relation to data centers today. It's worth taking a moment to look at each of the individual elements and see how they can be combined into a larger data center power concept.

First, the idea of "behind the meter" - what does this even mean? Simply put, it suggests that some form of power generation or storage be situated so that it replaces or supplements some of the power that would normally come from the utility - and thus be "metered". We've had this in various forms for years - backup diesel generators and UPS are both behind the meter. The big difference here is the idea of primary power vs backup power.

The most common concepts for behind-the-meter power generation is natural gas, either turbines or reciprocating engines. The turbines are more efficient and can result in a better effective cost per kwh - similar to aggressive utility costs in the mid single digits. They can also burn hydrogen - whenever that becomes available, which may be “never”. However, they are expensive and take some time to spin up. Reciprocating engines, on the other hand, are less expensive in terms of capex and start up much faster - however, they are far less efficient and can bring in energy costs in the low teens which may not be competitive.?

Second, what about energy storage? Again, we've had UPS systems and in-rack batteries for many years. But those are backup solutions - the idea of large scale energy storage is to make those batteries or other energy storage solutions into primary power. Chemical batteries have always been of questionable economics here. Utilization of pumped water, cryogenic gasses, hydrogen, and other energy storage technologies - as well as next generation battery chemistry are on the table.

So, how can this all work together? It's a concept that ASG calls "Three Plus S". Imagine a 300MW data center campus. Generally, it's only going to use 180MW of power in steady state on an average day. But we have to ask the utility for 300MW, even if it's not fully utilized - a measure that is resulting in more draconian take-or-pay provisions from utilities. But what if we did it a different way?

Let's say we took 150MW of power from the utility - not quite enough to cover an average day. But then we added 100MW of natural gas turbines, 100MW of renewables, and 50MW of 8-hour battery power. We'd be covering most of our base load with the utility power, and could use our batteries- charged from the renewables and our turbines - to cover the rest. We would be able to charge our energy storage from those renewables or from our turbines as needed, according to a Machine Learning model trained by local climate data and informed by our risk assessments and service level agreements. We would also be able to potentially sell peaking power back into the grid from the turbines or batteries as needed - lowering our effective utility cost per kwh.?

We could potentially pay for this by reducing our reliance on environmentally unfriendly diesel generators - after all, we would have multiple fractional power sources which could back each other up. We'd be able to build data center capacity in areas where the utility couldn't cover the full requirement, while essentially maintaining - or exceeding - the reliability of a utility-backed campus. The three pillars - utility, natural gas, renewables plus storage - "Three Plus S" - are a potent solution

So, what is holding this concept up? First, no one is quite sure what the optimum balance is between those three pillars. Second, there isn't yet a fully fleshed out economic model. Finally, there is currently a lack of confidence in moving forward largely because of the innate engineering and customer side conservatism that many engineers ascribe to. And yet, it's time. The first movers in these developments will gain tremendous economic and environmental advantages. Time to step it up to Three Plus S for datacenter development.