Show HN: PG-Capture – a better way to sync Postgres with Algolia (or Elastic)
6 comments
·March 1, 2025srameshc
Thanks for sharing, even though I don't use Algolia or Elastic but I love the idea of tracking Postgres Triggers and sending it to the queue and sending wherever you need it. Brilliant !!
nick-keller
Thanks! Syncing PG to another data store like Algolia or Elastic is just a very common use case that I use to pitch the idea. But Change-Data-Capture can be used for much more: emitting events when data changes, transforming data, caching data...
All of those use cases are really painful with raw table-level events.
cuuupid
Does this work out of the box with Prisma?
nick-keller
It does if you are using PG (other SQL databases will be added later). Under the hood, PG-Capture listens to raw Postgres events, it does not matter if the data was updated via an ORM (like Prisma), raw SQL, or even a developer's IDE...
nylonstrung
This looks awesome, was hoping for an easier way to use debezium for event capture and will try it
nick-keller
Happy if it helps! Feel free to share your feedback here or on GitHub once you do!
Hello HN! Keeping Elasticsearch or Algolia in sync with Postgres is a pain when your data spans multiple tables. Traditional CDC tools like Debezium capture table-level events but don’t help when you need to index a full entity composed of related records. That's why I built PG-Capture.
PG-Capture lets you define a schema as complex as you need, aggregate table-level events, and reconstruct structured objects spanning multiple tables. It then publishes them as meaningful domain-level events to any queue (RabbitMQ, SQS, etc.).
PG-Capture does NOT replace Debezium, it works on top of it (or any other event source). This keeps it flexible and tool-agnostic.
I'd love to hear your thoughts! Does this solve a problem you've run into? Would you use something like this in your stack? Feedback is welcome!