philippemnoel

10 ms·

91.
by philippemnoel 2y ago
This is partially true. You're right that the feature set is necessary, but it's now possible to do this in Postgres. ParadeDB pg_search bundles Tantivy, a Lucene-inspired library inside Postgres, to give users the feature set (BM
92.
by philippemnoel 2y ago
Keeping it in Postgres avoids needing to denormalize the data, which is a big pain point. ParadeDB pg_search is based on Tantivy, a Lucene-inspired library, so in some ways it allows you to both benefit from a Lucene-based system and also k
93.
by philippemnoel 2y ago
ParadeDB pg_search supports tokenizers in all major languages
94.
Postgres as a Search Engine(anyblockers.com)
155 points by philippemnoel 2y ago|39 comments
95.
by philippemnoel 2y ago
ParadeDB founder here -- We migrated the pg_analytics project to its own repo and will be adding JSON support!
96.
Query MinIO from Postgres(blog.min.io)
1 points by philippemnoel 2y ago|0 comments
97.
PostgreSQL Meets Object Storage(blog.min.io)
2 points by philippemnoel 2y ago|0 comments
98.
by philippemnoel 2y ago
That's so cool that he responded! Thank you for sharing
99.
by philippemnoel 2y ago
ParadeDB itself is AGPL, yes. Our core offering is pg_search, which offers Elasticsearch inside Postgres. What we build will be AGPL, and if pg_duckdb moves forward we will be happy to rebuild our analytics offering on top of it.
100.
by philippemnoel 2y ago
ParadeDB here -- agreed. The syntax for ParadeDB and Crunchy Analytics is similar, since we're both built as Postgres foreign data wrappers. pg_duckdb is the odd one out here, being built as a custom scan. I am confident they will conv
101.
by philippemnoel 2y ago
It seems like the team behind it is now working on pg_duckdb, though, which likely will supersede Citus columnar eventually? Is that not the goal with it?
102.
by philippemnoel 2y ago
There is a lot missing from it, as you know. We'd be happy to be part of the project if we get commit access/even partnership :)
103.
by philippemnoel 2y ago
This is a cool roadmap. I'm excited for Neon to get in the mix here, it's going to be a lot of work. My concern is... There are very few companies who care about doing the work in such a Postgres-idiomatic way. I suspect Neon wi
104.
by philippemnoel 2y ago
Hey Jerry, it's nice to see you here :) Truth is, the work you guys did at Hydra with the fork of Citus columnar is the more Postgres-idiomatic analytics engine in Postgres. It's a shame it was abandoned.
105.
by philippemnoel 2y ago
As Craig said, Crunchy has a very enterprise mature offering for analytics in Postgres and are very much leading the charge here. ParadeDB is built in a similar way, also ranking high on ClickBench, and is available in the open-source as we
106.
by philippemnoel 2y ago
ParadeDB has an open PR for time_bucket support via DuckDB here: https://github.com/paradedb/pg_analytics/pull/32
107.
by philippemnoel 2y ago
We've had 35 contributors in total on ParadeDB thus far, with 5 of them being core team members. That said, we measure traction in terms of users of the product rather than in terms of contributors to the project. We welcome contributi
108.
by philippemnoel 2y ago
While I agree with you that these are non-commercial, by now many of them have very big commercial backings. Many Postgres core contributors work at Microsoft, AWS, etc. who make billions of dollars selling Postgres-as-a-Service today. Thos
109.
by philippemnoel 2y ago
The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. We're hoping for a centralized ParadeDB project from which everyone can benefit.
110.
by philippemnoel 2y ago
That's fair. We use AGPLv3. I haven't seen any AGPL project that wasn't using v3, so we decided to keep it short for readability, but you bring up a very good point.
111.
by philippemnoel 2y ago
Blog author here -- I couldn't have said it better. If you'd like to meaningfully contribute to the project, we're hiring :)
112.
by philippemnoel 2y ago
pg_analytics maker here -- That's cool! We package ours in CNPG here: https://github.com/paradedb/helm-charts Would you recommend using Nix even in that context?
113.
by philippemnoel 2y ago
Blog author here. That's fair! We'll add horizontal scaling eventually, but for now, our customers (including some large brands!) have not needed it. Turns you single nodes are remarkably powerful nowadays
114.
by philippemnoel 2y ago
We have some API-compatibility in faceted search. But yes, we are not (today) a drop-in replacement for ES. We have many migrations from ES/OpenSearch and users find that converting their code over is well worth the savings in maintena
115.
by philippemnoel 2y ago
We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.
116.
by philippemnoel 2y ago
Blog author here. I couldn't agree more. Thank you for your kind words and for sharing the academic perspective of using the AGPL - super interesting!
117.
Why we picked AGPL(blog.paradedb.com)
267 points by philippemnoel 2y ago|305 comments
118.
by philippemnoel 2y ago
Blog author here -- You're right, they can. We're aware of this. But, for most cloud vendors, they do need to modify the code in order to make that possible (if only to integrate it within their stack). It then becomes a game of c
119.
by philippemnoel 2y ago
ParadeDB supports partial indexes as well: https://docs.paradedb.com/search/full-text/index#partial-bm2...
120.
by philippemnoel 2y ago
ParadeDB founder here. We are open-source: https://github.com/paradedb/paradedb . Very much not "invite only". We have hundreds of open-source deployments in production and several paying customers. Our bring-

More ›