Community Contributions

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 saw 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 a few things that I think have worked:

  • 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.”
  • 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 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 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.
  • 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.
  • Prioritize quality over quantity for content. 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 that wanted to contribute to the project … and now we have support for one of the most-spoken languages in the world.

ParadeDB is still early, but I'm incredibly proud of the community we are assembling. To preserve it, we have to continue to show up, listen closely, and make room for others to shape the work.

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.