#FerretDB 1.0 has been announced
Ferret is a proxy that sits between your #mongodb drivers & a #postgres db converting mongo queries into postgres SQL and using PG for the persistence.
I am finding myself at a complete loss as to any practical reason why someone would want to use this. The ONLY case i can make for it is that it satisfies people who are zealous about open source licenses and aren't happy with Mongo's.
@hobs this make take a couple toots. Please know that i'm honestly trying to work through the problem to understanding. I'm not trying to say "you're wrong". Going step by step through your points.
portability
How is this portable? You couldn't swap out PG for something else. I guess it'd let you port a Mongo centric codebase to PG but ...why would you want to?
stable api
the "stable api" is mongo's API so... switching to not-mongo is either no change or introducing risk
Valid, but if that was a priority mongo was a bad choice. BUT maybe mongo WAS a bad choice & we're in "dig ourselves out of a ditch" mode & trying to avoid a rewrite.
If SQL access is important it seems a bad choice to use this for anything new.
specializations
4a. vectors: MongoDB atlas has vector similarity search
4b. postgrest: mongo has Rest API
4c. gis: mongo has geospacial indexing
@hobs To be clear, I'm not a mongodb fanboy, and SQL is my favorite DSL ever. That being said MongoDB has come a long way since it's start and there are lots of great features available.
To me the only plausible use case for ferret is "shit we shouldn't have chosen mongo for our task and really don't want a rewrite"
that being said bad mongo results are almost always "we didn't take the time to learn what it means to use a document db and treated it like a relational one"
@hobs Ferret would make SO much more sense if they'd just pitch it that way, but they're pitching it as "hey this is a great choice to develop apps with" and... I just don't buy that.
as a very focused niche "help me escape mongo with minimal work" tool it looks incredibly valuable.
@masukomi
+100
I guess they know that people who want to switch will find #PG and Ferret on their own. So they are marketing to small new app developers that don't know how to use anything other than a graph db or doc store "catch all". Relational DBs are tough for some people. #Ferret might be the gateway drug for new developers.
@masukomi
Totally agree ... bad choice for anything new.
4. I had no idea. Thank you!
4a. Wonder how the atlas vector performance numbers stack up. PG's are at the bottom of the ranking for vectors: https://ann-benchmarks.com/
4c Wonder about GIS performance, imagine it's comparable to pg since it's mature technology #ANN#VectorSearch#VectorDB
Mongo users could port data into pg using existing #backup & #recovery infrastructure, then they'd have both SQL and mongo query/dump/load options for future #migrations
The pg API will lag mongo's and sunset existing features later. And #SQL api as a fallback
A mongo app could transition to pg incrementally or partially, increasing maintainability by using mongo queries and SQL queries where they make sense
Add comment