Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB acquires Voyage AI

investors.mongodb.com

Post reply on HN
Print view View original

31–40 of 172 posts

Re: MongoDB acquires Voyage AI

#31

Post by pphysch »

cpursley wrote: post #23

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

It's simply not that widespread of knowledge. Modern Postgres users would never suggest Mongo, but a generation of engineers was taught that Mongo is the NoSQL solution, even though it's essentially legacy tech.

I just ran into a greenfield project where the dev reached for Mongo, and didn't have a good technical reason for it beyond "I'm handing documents". Probably wasn't aware of alternatives. FWIW Postgres would've been a great fit for it, they were modeling research publications.

Re: MongoDB acquires Voyage AI

#32

Post by pphysch »

amazingamazing wrote: post #25
cpursley wrote: post #23

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

MongoDB is not the same as Postgres and jsonb. also, I'd challenge your thinking - ultimately the goal is to solve problems. you don't necessarily need SQL, or relations for that matter. that being said, naively modeling your stuff in mongodb (or other things like dynamodb) will cause you severe pain... what's also true, which people forget, is naively modeling your stuff with a relational database will also cause yo…

Then your implementation can be as simple as CREATE TABLE documents (content JSONB);. But I suspect a PK and some metadata columns like timestamps will come in handy.

Re: MongoDB acquires Voyage AI

#33

Post by kaycebasques »

infecto wrote: post #18

Only skimmed through the release..I hope they continue supporting the API but it comes with a little higher confidence that the company behind it is not collecting all your data. Voyage has some interesting embedding models that I have been hesitant to fully utilize due to the lack of confidence in the startup behind it.

This blog post outlines the new roadmap: https://www.mongodb.com/blog/post/redefining-database-ai-why...

Re: MongoDB acquires Voyage AI

#34

Post by gddgb »

cpursley wrote: post #23

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

[dead]

Re: MongoDB acquires Voyage AI

#35

Post by __jl__ »

kaycebasques wrote: post #33
infecto wrote: post #18

Only skimmed through the release..I hope they continue supporting the API but it comes with a little higher confidence that the company behind it is not collecting all your data. Voyage has some interesting embedding models that I have been hesitant to fully utilize due to the lack of confidence in the startup behind it.

This blog post outlines the new roadmap: https://www.mongodb.com/blog/post/redefining-database-ai-why...

They commit to supporting the API in step 1 but it's not entirely clear to me whether that commitment continues with step 2-3...

Re: MongoDB acquires Voyage AI

#36

Post by amazingamazing »

pphysch wrote: post #32
amazingamazing wrote: post #25

Earlier quoted context omitted.

MongoDB is not the same as Postgres and jsonb. also, I'd challenge your thinking - ultimately the goal is to solve problems. you don't necessarily need SQL, or relations for that matter. that being said, naively modeling your stuff in mongodb (or other things like dynamodb) will cause you severe pain... what's also true, which people forget, is naively modeling your stuff with a relational database will also cause yo…

Then your implementation can be as simple as CREATE TABLE documents (content JSONB);. But I suspect a PK and some metadata columns like timestamps will come in handy.

sigh - mongoDB is not the same as creating a table with jsonb. for one, you don't have to deal with handling connections. that being said, postgres is great, but it's not the same.

Re: MongoDB acquires Voyage AI

#37

Post by computerfan494 »

cpursley wrote: post #23

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

I will copy and paste a comment I wrote here previously:

"MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonably vendor-neutral and can be run locally, and the data modeling it encourages is both preferential for some people as well as pushes users to avoid patterns that don't scale very well with other models. Whether these things are important to you is a different question, but there is a lot to like that alternatives may not have answers for. If you currently or plan on spending > 10K per month on your database, I think MongoDB is one of the strongest choices out there."

I have also run Postgres at very large scale. Postgres' JSONB has some serious performance drawbacks that don't matter if you don't plan on spending a lot of money to run your database, but MongoDB does solve those problems. This new documentdb extension from Microsoft may solve some of the pain, but this is some very rough code if you browse around, and Postgres extensions are quite painful to use over the long term.

The reality is that it is not possible to run vanilla Postgres at scale. It's possible to fix its issues with third party solutions or cobbling together your own setup, but it takes a lot of effort and knowledge to ensure you've done things correctly. It's true that many people never reach that scale, but if you do, you're willing to spend a lot of money on something that works well.

Re: MongoDB acquires Voyage AI

#38

Post by pphysch »

amazingamazing wrote: post #36
pphysch wrote: post #32

Earlier quoted context omitted.

Then your implementation can be as simple as CREATE TABLE documents (content JSONB);. But I suspect a PK and some metadata columns like timestamps will come in handy.

sigh - mongoDB is not the same as creating a table with jsonb. for one, you don't have to deal with handling connections. that being said, postgres is great, but it's not the same.

Postgres has ways to simplify connection management, if that is a blocker for you (pooling, pgbouncer, postgrest, etc)

Re: MongoDB acquires Voyage AI

#39

Post by ecshafer »

cpursley wrote: post #23

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

I have seen a few rather large, production mongodb deployments. I don't understand how so many people chose it as their basis of their applications. There are a not-negligible amount of mongodb deployments I have seen that basically treat mongodb as a memory dump, where they then scan from some key and hope for the best. I have never seen a mongodb solution where I thought that it was better than if they just chose any sql server.

SQL or rather just some schema based database has a ton of advantages. Besides speed, there is a huge benefit for developers to be able to look at a schema and see how the relationships in the data work. Mongodb usually involves looking at a de facto schema, but with fewer guarantees on types relations or existence, then trawling code for how its used.

Post reply on HN