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

141–150 of 172 posts

Re: MongoDB acquires Voyage AI

#141

Post by Tanjreeve »

redwood wrote: post #96
delusional wrote: post #83

Earlier quoted context omitted.

> It's 2025 these features are not-negotiable for most use cases. Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime. It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.

MongoDB has had ACID transactions for many years. I encourage folks to at least read up on the topic they are claiming to have expertise in

Reputation matters. If someone comes to market with a shoddy product or missing features/slideware then it's a self created problem that people don't check the product release logs every week for the next few years waiting for them rectifying it. And even once there is an announcement people are perfectly entitled to have scepticism that it isn't a smoke and mirrors feature and not spend hours doing their own due diligence. Again self created problem.

Re: MongoDB acquires Voyage AI

#142

Post by aitchnyu »

schnebbau wrote: post #2

How does MongoDB still have that much available to spend? Everyone I know moved off it years ago.

Are they profitable, and at which point in time? How good of an investment was it? Sorry, my eyes were swimming in their financial report hosted in their domain.

Re: MongoDB acquires Voyage AI

#143

Post by Tanjreeve »

ecshafer wrote: post #39
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 a…

If you're scared of SQL/have a massive operations team to throw infrastructure problems over the fence then that would be a positive to push all complexity into the application code as you aren't the one paying that cost.

Re: MongoDB acquires Voyage AI

#144

Post by winrid »

redwood wrote: post #96
delusional wrote: post #83

Earlier quoted context omitted.

> It's 2025 these features are not-negotiable for most use cases. Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime. It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.

MongoDB has had ACID transactions for many years. I encourage folks to at least read up on the topic they are claiming to have expertise in

Last I checked they still didn't even implement pagination on their blog properly

Re: MongoDB acquires Voyage AI

#145

Post by winrid »

SEJeff wrote: post #74
999900000999 wrote: post #69

Earlier quoted context omitted.

Simple. Postgres is hard, you have to learn SQL. SQL is hard and mean. Mongo means we can just dump everyone into a magic box and worry about it later.No tables to create. But their is little time, we need to ship our CRUD APP NOW! No one on the team knows SQL! I'm actually using Postgres via Supabase for my current project, but I would probably never use straight up Postgres.

Postgres supports JSONB natively. It literally speaks mongo line protocol and you can shove unstructured json into it. It has supported this since 9.4: https://www.postgresql.org/docs/current/datatype-json.html

Yes but updating nested fields is last write wins, and with mongo you could update two fields separately and have the writes succeed, it's not equivalent.

Re: MongoDB acquires Voyage AI

#146

Post by winrid »

koakuma-chan wrote: post #91
beoberha wrote: post #64

Earlier quoted context omitted.

I think the amount of people working on large enterprise systems here is a lot smaller than one would think. Whenever a fly.io post about sqlite ends up in here, there are a scary amount of comments about using sqlite in way more scenarios than it should be.

Why would I use anything other than sqlite?

Query engine is not as good.

Re: MongoDB acquires Voyage AI

#147

Post by winrid »

hartator wrote: post #71
memco wrote: post #47

Earlier quoted context omitted.

Can you share more details about the conditions under which it is slow in recent versions? We moved from 3.x to 7 for our main database and after adding a few indexes we were missing we have seen at least an order of magnitude speed up.

Most regular inserts and regular selects: https://medium.com/serpapi/mongodb-benchmark-3-4-vs-4-4-vs-5... We have internally a benchmark with MongoDB 8.x, but same pattern of disappointing results.

As someone that has ran every version from 3.2 to 8 on small nodes and large clusters (~100+ nodes)...

8 is waaay faster in the real world. It's not really comparable. Your micro benchmark is comparing the few nanoseconds of the heavier query planner, but in the real world that query planner gives real benefits. Not to mention aggregations, memory management improvements, and improvements when your working set size is very large/larger than memory.

Re: MongoDB acquires Voyage AI

#148

Post by touche_bag »

hartator wrote: post #72
touche_bag wrote: post #56

Earlier quoted context omitted.

I think 8 was a release purely focused on performance, with some big improvements. Comparing 3.4 is kinda unfair.. You were fast with the tradeoff of half your data missing half the time

That might explain the write performance degradation, but not the reads.

Consistent reads also mean additional checks. I think the WT cache is also very double edged. Completely cripples the database when resource constrained and not sized correctly, while giving a huge boost when the environment is "right sized". Honestly, give 8.0 and tell me how it compares. Haven't touched ancient Mongo versions in a long time, so I have little intuition on how it compares.

Re: MongoDB acquires Voyage AI

#149

Post by touche_bag »

moralestapia wrote: post #58
touche_bag wrote: post #55

Earlier quoted context omitted.

Interesting take. Have you benchmarked models on your own data? Cause at this point everything is contaminated so I find it impossible to tell what proper sota is. Also - most folks still just use openai. Last time I checked, reranking always performs better than pure vector search. And to my knowledge it's still the superior fusion method for keyword and vector results.

In my experience, storing RAG chunks with a little bit of context helps a lot when doing the retrieval, then you can skip the whole "rerank" bit and halve your cost and latency. With embedding/generative models becoming better with time, the need for a rerank step will be optimized away.

Huh? Rerank is always a boost on top of retrieval. So regardless of the chunking method or model you use, reranking with a good model will always result in higher MRR. And improvements in embedding models also will never solve the problem of merging lexical and vector search results. Rank/score fusion are flawed since both are hardly comparable and boosting only works sometimes. Whereas rerankers generally do a pretty good job at this. Performance is indeed the biggest issue here. Rerankers are slow as hell and simply not feasible for some use cases.

Re: MongoDB acquires Voyage AI

#150

Post by touche_bag »

delusional wrote: post #83
threeseed wrote: post #77

Earlier quoted context omitted.

a) MongoDB has built-in, supported, proven scalability and high availability features. PostgreSQL does not. If it wasn't for cloud offerings like AWS Aurora providing them no company would even bother with PostgreSQL at all. It's 2025 these features are not-negotiable for most use cases. b) MongoDB does one thing well. JSON documents. If your domain model is built around that then nothing is faster. Seriously nothing…

> It's 2025 these features are not-negotiable for most use cases. Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime. It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.

100? I had a customer with 10k upserts incl merge logic for the upserts while serving 100k concurrent reads. Good luck doing that with a SQL database trying to check constraints across 10 tables. This is what Nosql databases are optimized for... There's some stand-out examples of companies scaling even mysql to ridiculous sizes. But generally speaking, relational databases don't do a great job at synchronous/transactional replication and scalability. That's the trade off you make for having schema checks and whatnot in place.
Post reply on HN