When people think about data centers, they usually think about servers, GPUs, electricity, and AI.
Very few people think about water.
That realization is what led me to start building AquaStat.
Why AquaStat?
Modern data centers consume significant amounts of water for cooling. Depending on the technology, climate, and workload, water usage can vary dramatically from one facility to another.
Finding reliable information about that usage, however, is often difficult.
Some facilities voluntarily publish sustainability reports. Others release only limited information. In many cases, information is scattered across government documents, environmental reports, local news articles, permits, or community discussions.
I wanted to build a platform that could organize this information into something developers, researchers, journalists, and the public could actually use.
What AquaStat Is
AquaStat is an API-first platform focused on collecting, organizing, and analyzing information related to data center water usage.
The long-term vision includes:
- A developer-friendly REST API
- OpenAPI documentation
- API key management
- A desktop control center
- A command-line interface
- Historical tracking
- Source attribution for collected information
- Transparent methodologies
- A modern TypeScript ecosystem
Rather than hiding calculations, I want AquaStat to explain where information comes from and how conclusions are reached whenever possible.
Technical Goals
I'm designing AquaStat around several principles:
API First
Everything should be accessible through documented APIs before being exposed through a graphical interface.
Strong Documentation
Documentation should be treated as part of the product, not an afterthought.
Reproducible Calculations
Whenever AquaStat estimates or derives values, the methodology should be understandable and repeatable.
Modern Tooling
The project uses a modern TypeScript stack with an emphasis on maintainability, testing, and developer experience.
Challenges
One of the biggest technical challenges isn't writing the API itself.
It's data quality.
Public information comes from many different sources:
- Environmental reports
- Government documents
- Company sustainability reports
- Local news coverage
- Community discussions
- Public datasets
Those sources often disagree with each other.
One of the goals of AquaStat is to preserve source attribution instead of pretending every number is perfectly known.
When information cannot be verified, it should be identified as uncertain rather than presented as fact.
What I'm Learning
This project has already pushed me to learn more about:
- API architecture
- Database design
- TypeScript
- Documentation systems
- Deployment
- Authentication
- Billing infrastructure
- OpenAPI
- Developer tooling
It's also reinforced how important good documentation and clear system design are when projects begin to grow.
What's Next?
The roadmap currently focuses on:
- Completing the billing and API-key system
- Expanding data collection workflows
- Improving the desktop control center
- Publishing SDKs
- Continuing to improve documentation
- Making the API easier for developers to integrate
Final Thoughts
AquaStat is still evolving and actively being worked on, but I'm excited to continue building it in public.
I'll be writing more about the architecture, technical decisions, lessons learned, and challenges along the way.
If you're interested in APIs, developer tooling, environmental technology, or open-source software, I'd love to hear your feedback and ideas.
Top comments (0)