In three years, Stormatics has grown from a one-person bet on a market gap to a team of eleven serving 35+ customers across 20 countries on five continents. Here is what that journey looked like – including the part where I almost shut the whole thing down.

On March 31, 2023, I incorporated Stormatics in Singapore as a private limited company. I had spent over two decades in the PostgreSQL ecosystem – 2ndQuadrant, EDB, OpenSCG, Percona – and for most of that time, I loved the work and the community around it. Starting a company was the furthest thing from my mind.

What changed was EDB’s acquisition of 2ndQuadrant in 2020. For 20 years, 2ndQuadrant had been the place you could go for deep, platform-agnostic PostgreSQL expertise. They worked with you regardless of which distribution you ran or which cloud you were on. They helped you with PostgreSQL, full stop. When that capability was absorbed into a product-led company, the market was left with a gap. And the gap stayed open.

At the same time, PostgreSQL adoption was accelerating faster than the available expertise could keep up. Banks, fintechs, government agencies, and SaaS platforms, all moving to Postgres for mission-critical workloads. The demand for specialized production support was growing rapidly. Yet most companies offering help tied their support model to their own product. Their assistance came with a prerequisite: adopt our platform first. Organizations running community PostgreSQL, or a managed cloud offering, or a distribution from a different vendor were largely left to figure it out on their own.

And here is a structural reality that deserves more attention: PostgreSQL still lacks a standardized certification programme. Compare that with Oracle. Oracle invested heavily in building certifications that produced a massive pipeline of Oracle-certified DBAs and developers. When you needed Oracle talent, you could find it. The certifications created a skills development path, and that path created a talent pool. PostgreSQL has yet to build anything equivalent. Skills development remains informal, and structured pathways into PostgreSQL specialization are still rare. The result? When an organization needs people who can manage their critical PostgreSQL database, finding them is genuinely difficult. This is simply how the ecosystem evolved. And it means the need for specialized PostgreSQL expertise is structural; it is baked into the landscape.

That is why I founded Stormatics. To provide deep PostgreSQL expertise through a 360-degree operational model, and to meet you where you are, on whatever platform you are running.

Year One: Faster Than Expected

The first year surprised us. We closed it out with 14 customers across 11 countries, published 63 blogs, delivered 5 conference talks, and logged 997 hours of direct customer support. We brought on 5 new team members. For a company built around a niche that many people called “too narrow”, that felt like strong validation.

The work itself was varied from the start. We migrated a fast-growing digital marketplace from Heroku to AWS, working around Heroku’s replication limitations by using WAL shipping through S3, completing the promotion in under 10 minutes and reducing active connections from 150 to 50 with PgBouncer. We helped a Middle Eastern government agency that was experiencing PostgreSQL outages on average 3 times a week after migrating from SQL Server. We built them a 3-node HA cluster with auto-failover and achieved zero downtime, all implemented remotely via screen-sharing sessions because their security protocols required it. We diagnosed index corruption caused by power fluctuations in a data centre for a video surveillance SaaS company, a problem that other vendors had declined to even investigate! And we identified a performance-degrading bug in AlloyDB for a client and facilitated their migration back to CloudSQL, completing it in two minutes inside a thirty-minute maintenance window.

These are production-grade problems. They show up when PostgreSQL meets real workloads at scale. And the pattern we kept seeing was that the people running these systems were smart engineers; they just needed access to someone who had seen these exact failure modes before. That is the gap we were filling.

Year Two: The Part Nobody Talks About

Then 2024 hit, and the traction stalled.

I am going to be honest about this because I think it matters. After a strong first year, we went through a long dry spell during which new projects remained out of reach. The pipeline was there. The conversations were happening. Yet contracts kept slipping. Months went by. Cash reserves kept shrinking.

I gave myself a deadline. If things didn’t turn around by then, I would shut the company down. I mean that literally. I was doing the math on wind-down costs.

We landed a contract 13 days before that deadline.

I share this because there is a version of the “startup anniversary post” that only tells the success story. The metrics, the growth, the logos. And all of that is real. Yet the space between Year One and now included a stretch in which the entire company was 13 days from ceasing to exist. Every founder I know has a version of this story. Most keep it to themselves. I think they should share it.

What I learned from that stretch is something I now consider a competitive advantage: the ability to operate lean, to be disciplined about where we invest, and to treat every single engagement as a privilege. Every customer who trusts us with their production database is betting on us. We remember that every day.

Year Three: Finding Our Stride

Coming out of that low point, something shifted. The work got deeper, the engagements got longer, and word of mouth started compounding.

The technical challenges grew more complex, too. TimescaleDB compression hitting row-size limits on 900-column tables. Continuous aggregate joins breaking data integrity in ways that go beyond what the documentation covers. A fintech client’s production environment where WAL files had grown to 1.8 TB – consuming nearly all of the 2 TB disk – because a Debezium logical replication slot had stopped committing events to Kafka. DELETE-heavy workloads bloating terabyte-scale tables and overwhelming autovacuum. Teams reaching for logical replication where physical replication was the right call, and paying for it with production stalls. These are the kinds of problems that find you when the ecosystem trusts you to solve them.

Today, Stormatics is a team of eleven. Our consulting bench includes people like Chris Travers, Kirk Roybal, and Kaarel Moppel – names that the PostgreSQL community knows and trusts. Our consultants bring the day-to-day operational rigor that keeps production databases healthy around the clock.

We have served 35+ customers across more than 20 countries on five continents. Our work spans fintech, sustainable energy, government technology, SaaS, and healthcare. We operate from Singapore and Texas, and we deliver 24×7 follow-the-sun coverage because databases run around the clock, and the coverage they require should too.

We have published 8 case studies, 5 whitepapers, and maintained an unbroken publishing cadence of technical blog content every single month since April 2023 – 36 months and counting. We have developed Signature Methodologies for performance optimization, high availability, and remote engagement, because repeatable excellence requires repeatable processes.

We built partnerships with organizations like EDB, Tiger Data, and DBtune; relationships where these companies trust us to represent PostgreSQL expertise to their own customers. When the ecosystem’s most recognized names need a specialist they can put in front of their clients, they call us. That is a statement about the standard of work we deliver, and we take it seriously.

What Three Years Taught Us

A few things stand out when I reflect on what we have learned.

The problems are getting harder, and that is a good thing. PostgreSQL’s success means it is being deployed in increasingly complex environments. Multi-cloud. Hybrid architectures. Mission-critical workloads that demand 99.99% uptime. CDC pipelines, logical replication topologies, terabyte-scale tables with aggressive maintenance windows. The database itself keeps getting better. The operational complexity around it keeps getting steeper. This is good for our business, and it means we have to keep getting better too.

Meeting people where they are is a real practice, every day. We work with Crunchy Data deployments, EDB Postgres Advanced Server, open-source PostgreSQL, AlloyDB, CloudSQL, Azure Flexible Server, Cosmos for PostgreSQL, TimescaleDB, and every combination of cloud, on-premise, and hybrid you can think of. That platform-agnostic stance is fundamental to who we are. It is also, I think, one of the main reasons organizations choose us. They want advice that is purely about PostgreSQL, independent of any product agenda.

Depth beats breadth. We are a PostgreSQL company. PostgreSQL is all we do – every hour, every engagement, every hire. That singular focus is what allows us to go deep on the problems that matter. When a customer calls because their database is throwing unpredictable exceptions and every other vendor has declined to investigate, they need someone who will dig into the logs, trace it to index corruption caused by a hardware glitch, and resolve it the same day. That is the value of specialization.

The best content comes from real work. Every blog post we write, every conference talk we give, every whitepaper we publish, it comes from actual engagements. Real incidents, real architectures, real lessons. We write about what we see in production. That is what makes it useful.

Looking Ahead: Year Four and Beyond

DBA as a Service is now our flagship offering. This is where the market is pulling us, and it is where we are going to invest most heavily.

The model is straightforward: we become the full PostgreSQL operations team embedded in your workflow. 24×7 coverage. Monitoring. Performance tuning. Incident response. Health checks. Knowledge transfer. The kind of depth that requires an entire team of specialists working together.

What makes this interesting going forward is the role of AI augmentation. We are increasingly building AI into our delivery workflow to make the judgment of experienced PostgreSQL professionals faster and more consistently available. AI handles the first-line triage. It surfaces the patterns. It catches the things that would otherwise slip through at 3 AM. And then our people do what people do best: make the call on how to handle it.

I believe this is the future of database operations. The combination of AI and human expertise, where AI raises the floor, and experts raise the ceiling.

Thank You

To our customers: thank you for trusting us with your production databases. Every engagement we take on is a responsibility we hold closely.

To our team and everyone who has been part of this journey, thank you for building something I am proud of.

To the PostgreSQL community: thank you for building the database that makes all of this possible. We are here to make sure it runs the way it deserves.

Three years in. And we are just getting started.