Philippe Noël

I used to believe that solving hard technical challenges was the most rewarding part of building a technical product. As satisfying as that is, I may have found something even more fulfilling: witnessing strangers become contributors.

ParadeDB is two years old now. In 2023, Ming and I started it as an open-source database that brings BM25 full-text search and fast analytics support to Postgres. We observed how often Postgres users encountered limitations when building with Elasticsearch: denormalization, lack of JOINs, and operational headaches from syncing with Postgres. Our goal was to create a Postgres-native alternative.

We didn’t know what to expect. This was our first serious open-source project. We chose the model to simplify developer adoption and shorten the feedback cycle. We never really expected external contributors to join in.

I’ve given a lot of thought to why the community has welcomed us so openly and why many smart, busy people have made time to contribute. Perhaps it’s just the problem that we’re working on, but I suspect other traits of ParadeDB have helped draw people in. Here are some of the principles we followed that I think have helped:

• Work hard. People respect effort, even when the product is not yet complete. I firmly believe our users and design partners doubled down on their support despite encountering bugs because they saw how quickly we would patch them.

• Be genuine. We spent our first year focused on helping people, not selling to them. That mindset centred our community interactions around feedback and adoption. Ming and I used to tell ourselves, “We won't try to sell this product until a few companies reach out to adopt it. Only then will we feel we have made something valuable enough to have earned the right to sell it.”

• Be honest. Closed-source software companies often promise features that don’t exist yet. In open source, users can simply read your code. There’s no point in misrepresenting the truth. We found that being open about what works and what doesn't (yet) encourages trust. In turn, it fostered a community willing to help fill in the gaps.

• Be transparent. From day one, we’ve been transparent about our goal to build a sustainable, open-source business on top of ParadeDB. That means being thoughtful about choices like licensing. Unfortunately, many companies today use open source as bait—their code is open source, but it is buried behind deceivingly restrictive (and often bespoke) licensing terms. We chose the AGPL to ensure transparency with our users about what they can expect from ParadeDB. No bespoke license, no rug pull.

• Be reachable. We strive to respond to every user within 24 hours and monitor ParadeDB mentions across social media platforms. Many users have been surprised to see me reply directly to their posts, tweets or questions. We strive to compensate for missing features with support and service.

• Prioritize quality over quantity. Last year, we published six blog posts. That’s it. Each one had something meaningful to say. This year, we want to write more, but only because we’re encountering more interesting problems as the product evolves. We don’t chase volume. We strictly focus on things that are intellectually interesting to us, because only then can we expect them to be interesting to others.

• Work on something you’re passionate about. Passion is contagious. Every day, we wake up and are excited to work on ParadeDB. We’re excited to engage with the people adopting it. I like to think that people can sense our passion and that it draws them into the project. 

• Work on something people already like. People love Postgres. It has a passionate user base that wants to see it get better. In a way, Postgres is the “Linux of databases”. It’s free, extensible, and open-source. This has created a fervent and dedicated community, and by working to improve Postgres, we benefit from that existing goodwill. People root for us because they care about the foundation we’re building on.

• Position against something people dislike. Elasticsearch is widely used, but its limitations are well known. By offering an alternative that addresses familiar pain points, we immediately connect with a broad audience. Said bluntly, the enemy of my enemy is my ally.

I was inspired to write this post after two contributors came together to build Chinese language support into ParadeDB. Languages need tokenizers to break down text into component words. In April 2025, someone raised a PR that integrated ParadeDB with the Jieba tokenizer. Soon, documentation and stopword filter support were added. Just two contributors that we’ve never met and who wanted to contribute to the project … and now we have support for one of the most spoken languages in the world.

A thank you to everyone who has contributed. You’ve made ParadeDB better. If you're curious and would like to get involved, check out our CONTRIBUTING.md! And if you're interested in contributing full-time, we're hiring.

We raised our Series A a few months ago. When we did, we were a team of 4. We're now 6, and I'm working to grow the team to around 8.

What we’ve found is that successfully building devtools or infra isn’t a function of scaling massive teams with sprawling departments. Instead, you want to stay small and focused, recruiting the people who care about what’s being built and are the best in their respective fields. Why? Because our audience is discerning.

We’re not a typical SaaS tool, like a sales product. Those probably should scale early, even if it means a few bugs along the way. Their audience is forgiving. Ours isn’t. Devs will onboard, kick the tires, and jump ship if they detect any non-trivial problems. If a sales tool breaks, a few deals might get delayed. If an infra product breaks, the entire application can fail.

Meticulously-built devtools have a history of succeeding in the endgame. They scale more slowly at first, working closely with a handful of design partners on their way to version 1.0. Then, they hit an inflection point and take the world by storm. Elasticsearch, Snowflake, ClickHouse and MongoDB all followed this very trajectory. In recent days, Neon, a database that made huge strides towards a truly serverless Postgres, sold for $1B despite being early in its growth curve. There’s a long-term value in top-tier products, and top-tier products are built by a small group of truly exceptional and motivated people.

So, how do you hire the best? That’s the hard part. You can’t just wave money around and expect the best people to flock towards you. Instead, building a talented team is about earning the respect of the maisons in the field.

At ParadeDB, we've seen success on three venues: (a) conferences, (b) GitHub stalking, and (c) publishing content.

1. Recently, I spoke at Microsoft's Postgres conference called POSETTE. You can find my talk here. Conferences are a great way to share our work, build credibility, and meet phenomenal engineers. I regularly meet people who have watched one of my talks, and I often share my CMU DB seminar with prospective candidates when doing outreach. It's proven to be an invaluable way to showcase our work to future hires. It might not be the most scalable strategy—there are only so many database conferences—but given our gradual and piecemeal hiring pace, it’s a fairly decent option.
2. Then there’s GitHub stalking, and despite the slightly nefarious name, it’s a fair and transparent way to find talent. Especially in the world of open-source, GitHub is a window into who is contributing what. Most projects, despite having tens or hundreds of contributors, are often really only built by the top ~5 or so contributors. These top performers are the people we need at ParadeDB. Unsurprisingly, they are hard to convince and highly sought-after. To catch their attention, we need a way to stand out and communicate why we’re cool.
3. Which brings me to the final strategy: content. We write about our problems. And we have a lot of problems. Writing technical content forces us to think critically about our product while opening the conversation to the community. Content has already proven effective at hiring— Stu joined us after reading our post on block storage. Technical content is a window into how much we care about the product’s quality and precision. Talented people look for places where the calibre of engineering matches theirs, and great technical content is perhaps the single best way to demonstrate our standards.

In devtools, the best product is usually the one that wins. As a result, we need these rockstar developers. The best products are built by the best engineers, period. Our engineering time isn’t spent installing packages, building integrations, or refactoring SQL queries—it’s optimizing how we lay data out on disk and 100X-ing our write throughput. These are problems we’ve repeatedly overcome strictly because our engineers are amazing.

Hiring is hard, and these two principles are how we’ve learned to do it well:

1. Hang out where the top engineers in your space hang out, whether in real life (conferences) or online (GitHub repos).
2. Show them you're one of them by sharing what you’re building, be it through conference talks or write-ups. If you aren't one of them yet, become one. The best developers want to work with the best.