Data Centers Are Abusing Concrete

Imagine building this without concrete. | Getty Images
"Those who talk should do and only those who do should talk."
- Nassim Nicholas Taleb
Data center owners have a concrete problem.
Most of them just do not see it yet.
Concrete is not the expensive shiny part of a data center. It is not the chiller. It is not the switchgear. It is not the server rack. It is not the copper package everyone is chasing.
So it gets treated like a commodity.
That is the mistake.
Concrete may be a small percentage of the total project cost, but it is one of the first materials that can make or break the schedule.
No foundations.
No structure.
No dried-in building.
No real start for the mechanical and electrical work everyone actually cares about.
That is the funny thing about data centers. The industry acts like concrete is just dirt, rock, cement, and water. Then it turns around and demands that this “simple” material carry every competing project goal at the same time.
Lower carbon.
Faster schedule.
Lower cost.
Same strength.
Same durability.
Same finish.
Same ACI requirements.
Same aesthetic expectations.
Same everything.
And when the mix gets pushed too far, the schedule gets compressed, the cement content gets reduced, the supplementary materials change, the local aggregates behave differently, and the concrete contractor raises concerns, the answer is often some version of this:
Here you go. You deal with it.
That is not a concrete plan.
That is wishful thinking with a purchase order attached to it.
The data center market is moving fast because the race for AI is moving fast. These projects are getting bigger, more remote, and more complicated. Many of the new sites are not sitting in mature metro markets with endless labor, supply, batch plant capacity, haul routes, and material redundancy.
They are being pushed into rural areas where the power may be available, the land may be available, and the politics may work.
But concrete still has to get there.
The cement has to get there.
The aggregates have to get there.
The sand has to get there.
The trucks have to run.
The batch plant has to produce.
The finishers have to be available.
The quality control has to be real.
And none of that magically happens because the owner has a carbon target and a turnover date.
This is where the data center world needs to grow up a little.
If concrete is critical path, then treat it like critical path.
Do not wait until the design is already locked, the schedule is already blown up, and the procurement team is already squeezing the last pennies out of the package.
Bring the concrete people in early.
Bring in the producer.
Bring in the concrete contractor.
Bring in the testing agency.
Bring in the structural team.
Bring in whoever is responsible for the carbon accounting.
Then have the grown-up conversation before the job starts.
What materials are actually available near the site?
What cement is actually being produced in that market?
What fly ash, slag, limestone, natural pozzolans, or other cementitious materials are actually available at scale?
How will the mix perform in the local climate?
What does early strength need to be?
What does the finishing window need to be?
What is the real placement sequence?
What happens if the low-carbon mix slows down set time?
What happens if the SCM supply gets interrupted?
What happens if the batch plant cannot keep up?
What happens if the mix meets the carbon target but creates schedule damage somewhere else?
These questions are not anti-sustainability.
They are anti-stupidity.
There is a difference.
Owners and developers want lower embodied carbon. Fine. That conversation is not going away. The big technology companies are global companies. They have ESG targets, scope three reporting, investor pressure, public pressure, internal policies, and marketing pressure.
That is the world they operate in.
But concrete chemistry does not care about your press release.
A mix design is not a spreadsheet cell.
You cannot just reduce cement, swap in whatever replacement material sounds good, run an AI optimization model, and assume the field will make it all work under a brutal schedule.
Concrete has chemistry.
Concrete has timing.
Concrete has heat.
Concrete has water demand.
Concrete has finishing behavior.
Concrete has strength gain.
Concrete has durability concerns.
Concrete has local material variation.
Concrete has real people placing it in real weather with real trucks showing up at real intervals.
Ignore that, and you are not reducing risk.
You are just moving the risk downstream to the people with the least control over the decision.
That is usually the ready-mix producer and the concrete contractor.
They get handed the target.
They get handed the schedule.
They get handed the spec.
Then they get blamed when the chemistry does not behave like the owner’s carbon model said it would.
That is a bad way to build.
Especially when the better answer is sitting right in front of everyone.
Use less concrete.
Not weaker concrete.
Not mystery concrete.
Not a chemistry experiment dumped on a mission-critical job.
Less concrete through smarter design.
Leaner structures.
Better coordination.
More efficient rebar layouts.
Cleaner load paths.
Less waste.
Better slab planning.
Better site logistics.
Better sequencing.
That is where the real opportunity sits.
If an owner wants lower carbon, the first question should not be, “How much cement can we strip out of the mix before it becomes someone else’s problem?”
The better question is, “Why are we using this much material in the first place?”
That answer may reduce carbon.
It may reduce cost.
It may reduce schedule.
It may reduce truck traffic.
It may reduce batch plant pressure.
It may reduce the chance of quality problems.
That is the kind of low-carbon strategy the construction side can actually get behind.
Not because it sounds good in a sustainability report.
Because it makes the job better.
The other problem is procurement.
Data centers are often built in silos. The building package has concrete. The site package has concrete. The substation has concrete. The roads have concrete. The adjacent power plant may have concrete. Each package may be buying from the same local material market without a coordinated plan.
That is how a “small” material becomes a bottleneck.
Concrete may be a small percentage of the total spend, but it can consume a huge amount of local supply.
Aggregates are local.
Sand is local.
Ready-mix delivery is local.
Labor is local or regional.
You cannot solve that with a national purchasing agreement and a nice-looking carbon dashboard.
On a gigascale project, concrete logistics should be part of the earliest planning conversation.
Where is the batch plant?
Is it existing or temporary?
How much production capacity is available?
Where are the aggregates coming from?
How long are the haul routes?
Can the road network handle the trucks?
What happens during peak placement days?
Who controls the mix designs across the different scopes?
Are the same materials being used across the site, or is every package creating its own little science project?
That last one matters.
If the owner wants consistency, then the project needs consistency.
Common materials.
Common expectations.
Common testing plans.
Common approval paths.
Common mockups.
Common understanding of what “low carbon” actually means on that site.
Not generic low carbon.
Not low carbon from a brochure.
Low carbon that works with those materials, that producer, that schedule, that placement method, that finish requirement, and that climate.
There is nothing wrong with innovation.
There is nothing wrong with new cement technologies.
There is nothing wrong with testing different binders, different cementitious materials, or different optimization tools.
The issue is scale.
A data center is not the place to confuse pilot-project thinking with production thinking.
If a material cannot be supplied at the volume the project needs, it is not a project solution. It is a sample.
If the mix cannot hit the schedule requirements, it is not a project solution. It is an idea.
If the finishers cannot place and finish it consistently, it is not a project solution. It is a liability.
Owners and GCs need to stop pretending the concrete industry is resisting change just because people ask practical questions.
“Where are we getting it?”
“How much is available?”
“How does it set?”
“How does it finish?”
“How does it cure?”
“What happens in cold weather?”
“What happens in hot weather?”
“What happens when the schedule moves?”
Those are not excuses.
Those are the questions that keep the project from becoming a mess.
The data center industry is very good at giving mechanical and electrical trades a seat at the table early.
That makes sense. Those systems drive the business model.
But concrete needs to be at the table too.
Not because concrete is glamorous.
It is not.
Concrete needs to be at the table because everything else sits on it.
The owner may not care about concrete.
The servers do not care either.
But the building does.
And if the building is late, nobody gets paid for being dismissive about the material that held up the start of the job.
The industry can keep treating concrete as a cheap carbon offset tool.
Or it can treat concrete as a critical path system that needs planning, coordination, testing, and respect.
One of those paths builds data centers faster.
The other one creates more meetings, more finger-pointing, more failed expectations, and more people asking why the “simple” concrete package became a problem.
Data center owners want speed.
They want cost control.
They want lower carbon.
They want predictable delivery.
They can have a better shot at all four.
But not by abusing the concrete and telling the producer and contractor to figure it out later.
Bring them in early.
Design leaner.
Use materials that can actually scale.
Test with the real local materials.
Coordinate the site-wide concrete demand.
Mock it up before the project is screaming.
Then build.
That is not anti-progress.
That is how progress survives contact with the jobsite.




