Why this exists
Mission, Vision, Strategy, Values
The mission, the vision, the strategy, and the values behind YeSQL — stated in full, not as a slogan.
Mission
Bring open source into the enterprise.
Vision
The bridge between enterprise engagement and open source, blind spots included.
Strategy
User priorities, knowledge transfer, sustainability, fast iterations.
Values
Nine principles, from autonomy to fast iterations.
Mission
Bring open source into the enterprise.
Make it so companies can get the same trust and accountability structure from PostgreSQL and its open source ecosystem that they currently only get from a proprietary vendor — without the vendor lock-in, and the total cost of ownership that comes with it. Companies rarely buy proprietary software for its engineering; they buy the contract that keeps the person who chose it from being the one who gets blamed.
Vision
Bridge two different ways of working: how the enterprise is used to operating — subcontracting, time-and-materials or fixed-price, licensing, support lines — and how open source actually works. That model has already proven itself: it produces the better result on everything that counts — quality, engineering, production fitness, fit for the problem. PostgreSQL is the clearest proof of it: on DB-Engines’ own ranking, it’s the only system in the top four still gaining ground while Oracle, MySQL and SQL Server are all losing it — and per the Stack Overflow Developer Survey, it’s “the most desired and the most admired technology in your category,” ranked highest on both since 2023.
Open source has one structural blind spot: what no volunteer is willing to work on remains a gap, in any project. In the PostgreSQL community today, that gap sits around archiving and, more broadly, the production-architecture tooling that wraps the core — core PostgreSQL development itself is well-funded and well-staffed; what surrounds it in production is not always. Take high availability and disaster recovery: today’s tooling splits them along a technical line — HA on one side, DR bundled with backups on the other — when what users actually want is HA and DR together, with backups as its own separate concern. The next version of pg_auto_failover fixes exactly that.
The ecosystem I maintain is meant to help with production architecture (pg_auto_failover, pgextwlist, pginstall, pgcopydb) and with migrating onto PostgreSQL (pgloader, pgcopydb).
Strategy
- 1
Open source support, user priorities
Development follows real production needs, arbitrated by a coherent technical vision.
- 2
Empowerment through knowledge transfer
The book and courses of The Art of PostgreSQL give teams the means to understand, not just to use.
- 3
A sustainable business model
Built to last, without depending on fundraising or an acquisition.
- 4
A working prototype beats a design document
Decisions are settled on running code, not on specifications.
Values
- 01
Autonomy
- 02
Technical excellence
- 03
Respect for individuals over process
- 04
Service to users
- 05
Technique in service of people, not the reverse
- 06
Concrete decisions, no committee politics
- 07
Skill transfer
- 08
Continuous improvement
- 09
Fast iterations