Why I Dare to Call Myself a “PostgreSQL Database Recovery Expert”

Thanks to the China PostgreSQL Association, and thanks to Qida. Becoming a PostgreSQL ACE is also a recognition of the work I have done over the past year and more.

Why Call Myself an Expert?

The title I chose for myself is “PostgreSQL Database Recovery Expert.” I also prefer to use this title when I attend other events.

At an event at Xi'an University of Posts and Telecommunications last week, I asked myself: how can someone so young feel comfortable calling himself an expert? What gives you that confidence?

My answer on stage was:

You can call yourself an expert when you believe that no one is doing better work than you in a particular field—until someone steps forward to challenge you. Fortunately, no one has questioned my professional ability in PostgreSQL unconventional recovery yet, so I will keep using the title.

What Is Missing in PostgreSQL Unconventional Recovery?

There is something interesting about this field. Oracle recovery, MySQL recovery, and SQL Server recovery all have many people who have worked in them for years. Even a search on Taobao returns plenty of results.

PostgreSQL unconventional recovery is more awkward by comparison. Many people do not know which scenarios are recoverable and which are not. Search online for a particular PostgreSQL unconventional recovery scenario, and most articles are little more than tool showcases: they line up various open-source utilities and tell you which one to try in one situation or another.

But what about accuracy? What about reliability?

To be blunt, from my perspective, there is not much to praise.

Most of these tools are designed from the perspective of the database kernel. Very few people truly consider the user's situation: what actually happened at the incident site, how much data remains, how to judge whether recovery is still possible, and how to export as much data as possible with confidence.

Why Was PostgreSQL Unconventional Recovery Neglected for So Long?

This brings me back to the earlier question: why did no one seriously work on PostgreSQL unconventional recovery in the past? I think the main reason was a lack of commercial incentive. PostgreSQL users had neither the mature willingness to pay found among Oracle users nor the enormous user base that MySQL accumulated during the LAMP era. With limited demand, there was naturally little incentive for sustained development.

That is the gap I happened to find.

And it was a large one. When I entered the field in early 2025, PostgreSQL unconventional recovery was still largely dependent on the unstructured growth of the community's open-source ecosystem. There was no methodology that truly belonged to PostgreSQL unconventional recovery.

How PDU Got Here

PDU moved forward one step at a time: first offline data extraction, then recovery through WAL data mining, and finally fragment-scanning recovery and recovery without a data dictionary. I have tried to incorporate into PDU the cases I have encountered, the mistakes I have made, and the experience that can be reused.

Open Source, Competition, and the Real Barrier

I have already open-sourced the first two capabilities for everyone to use free of charge.

PDU open-source repository: https://github.com/wublabdubdub/PDU-PostgreSQLDataUnloader

That does, of course, help potential competitors. But I have benefited greatly from the PostgreSQL open-source ecosystem, and I am happy to contribute something back to the community so that this positive cycle can continue.

Of course, if I call myself an expert, I also need to keep some core technology in hand. I am confident that, for the disk-fragment scanning and recovery without a data dictionary mentioned in my profile, no one in the community currently does better work than I do.

It is also possible that masters outside the community have already developed these skills and are quietly making money from them. If so, I would be glad to hear from you and compare notes privately.

A Final Note

That is all for today. Once again, thank you for your support.