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

161–170 of 172 posts

Re: MongoDB acquires Voyage AI

#161

Post by riku_iki »

theamk wrote: post #158
riku_iki wrote: post #136

Earlier quoted context omitted.

Are you aware: 1. That PgSQL also has issues in jepsen tests? 2. of any distributed DB which doesn't have jepsen issues? 3. It is configurable behavior for MongoDB: can it lose data and work fast, or work slower and do not lose data. There is no issues of unintentional data loss in most recent(5yo) jepsen report for MongoDB.

PgSQL only defect was anomaly in reads which caused transaction results to appear a tiny bit later, and they even mentioned that it is allowed by standards. No data loss of any kind. MongoDB defects were, let's say, somewhat more severe [2.4.3] "In this post, we’ll see MongoDB drop a phenomenal amount of data." [2.6.7] "Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale…

In attempt to understand your motives in this discussion, I would like to ask question:

* why you are referring on 12yo reports for very early MongoDB version?

Re: MongoDB acquires Voyage AI

#162

Post by Tostino »

itake wrote: post #140
riku_iki wrote: post #100

Earlier quoted context omitted.

things still can be true, even if being wrapped into meme videos by haters..

Postgres has replicas? Most people use those for reads and a master writes.

This can take you really damn far.

I've been playing with CloudNativePG recently and adding replicas is easy as can be, they automatically sync up and join the cluster without you thinking about it.

Way nicer than the bare-vm ansible setup I used at my last company.

Re: MongoDB acquires Voyage AI

#164

Post by jamesrr39 »

threeseed wrote: post #77
jamesrr39 wrote: post #67

Genuine question: I appreciate the comments about MongoDB being much better than it was 10 years ago; but Postgres is also much better today than then as well. What situations is Mongo better than Postgres? Why choose Mongo in 2025?

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…

Thanks for these comments, I appreciate it.

Although I would point out:

> scalability [...] no company would even bother with PostgreSQL at all

In my experience, you can get pretty far with Postgresql on a beefy server, and when combined with monitoring, pg_stat_statements and application level caching (e.g. the user for this given request, instead of fetching that data on every layer of the request handling), certainly enough most businesses/organisations out there.

Re: MongoDB acquires Voyage AI

#165

Post by hartator »

winrid wrote: post #159
hartator wrote: post #152

Earlier quoted context omitted.

Can you share some data about this? Here's another dataset about performance regression doing `$inc`s as fast as possible on the same object. Mongo 3.4.24: 332,037 stats update in 100s. (3,321 stats updates per s) Mongo 8.0.4: 287,553 stats update in 100s. (2,876 stats updates per s) (higher is better)

Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow. Setup a clone of prod and build a tool to replay your traffic to it. I have lots of data from datadog and ops manager but not going to take the time to publish ATM. I just moved a 4tb deployment from 3.2 to 7. It cut max query t…

> Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow

It was for us. API calls that need to aggregate stats on same ID. We found a way around, but it would not have been an issue if MongoDB 8 was like 2x faster.

> I just moved a 4tb deployment from 3.2 to 7. It cut max query time by about half. I actually went to instances with half the cpus, too (although I switched from ebs to ssds).

Just single-core performance improvement in the last 10-year might explain your outperformance.

Re: MongoDB acquires Voyage AI

#166

Post by eudoxus »

codr7 wrote: post #107
markus_zhang wrote: post #40

Looks like everyone is jumping into the AI game. Is there a bubble?

Whatever respect I had left for MongoDB just went out the window, the last thing I want in my database is AI.

Aside from the MongoDB of it all, wheres the issue with adding "AI" here? As I understand it this is just vector types, similarity searches, embedding indexes, and RAG capabilities.

All of which are just data storage/retrieval mechanics and custom types. This isn't adding some omnipotent AI agent to run/manage/optimize your DB or otherwise turn it into some blackbox gizmo.

Re: MongoDB acquires Voyage AI

#167

Post by SEJeff »

winrid wrote: post #145
SEJeff wrote: post #74

Earlier quoted context omitted.

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.

Can you provide an example or documentation please?

Re: MongoDB acquires Voyage AI

#168

Post by winrid »

hartator wrote: post #165
winrid wrote: post #159

Earlier quoted context omitted.

Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow. Setup a clone of prod and build a tool to replay your traffic to it. I have lots of data from datadog and ops manager but not going to take the time to publish ATM. I just moved a 4tb deployment from 3.2 to 7. It cut max query t…

> Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow It was for us. API calls that need to aggregate stats on same ID. We found a way around, but it would not have been an issue if MongoDB 8 was like 2x faster. > I just moved a 4tb deployment from 3.2 to 7. It cut max query time…

> Just single-core performance improvement in the last 10-year might explain your outperformance.

Nope, after migration max query time was still over a minute in some cases. What makes the biggest difference is performance tuning. After a week or so of index tuning, I got max index time below 6s. If Mongo makes each query take 2ms instead of 1ms, it literally doesn't matter to that customer or their customers, since it's just noise at that point. The old instances were M5s, so not that old.

The point is that the few nanoseconds difference you're measuring is not what you spend the most time on, usually.

Also you mentioned write performance. If you set journal commit interval to 500ms or something, then you can easily beat the old 3.2 write speeds, since if you're using 3.2 you probably don't care that much about journal commit intervals anyway ^_^

Re: MongoDB acquires Voyage AI

#169

Post by codr7 »

eudoxus wrote: post #166
codr7 wrote: post #107

Earlier quoted context omitted.

Whatever respect I had left for MongoDB just went out the window, the last thing I want in my database is AI.

Aside from the MongoDB of it all, wheres the issue with adding "AI" here? As I understand it this is just vector types, similarity searches, embedding indexes, and RAG capabilities. All of which are just data storage/retrieval mechanics and custom types. This isn't adding some omnipotent AI agent to run/manage/optimize your DB or otherwise turn it into some blackbox gizmo.

Oh I'm pretty sure that will be the next step, given the direction we're moving in and the lack of common sense and responsibility on display.

I see GenAI as a stop gap solution at best, not really optimal for any problems; and AGI is a major distraction from finding good solutions to important problems.

The wild goose chase to apply GenAI to everything has serious consequences.

People are so excited about the fact that a computer can sort of drive a car that they don't even stop to consider that a human driver that randomly fails the same way would never get a license, and rightly so.

So excited about the fact that a computer can sort of write functional code that they don't stop to consider that any human developer that fails randomly the same way would never get a job, and rightly so.

We're already applying it to weapons/warfare, which is obviously a very bad idea.

I'm sure the technology will improve, but never to the point where it's reliable. It will fail randomly less often, but the magnitude of its failures isn't going anywhere.

Re: MongoDB acquires Voyage AI

#170

Post by winrid »

SEJeff wrote: post #167
winrid wrote: post #145

Earlier quoted context omitted.

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.

Can you provide an example or documentation please?

When you write to a postgres jsonb field it updates the entire JSONB content, because that's how postgres's engine works. Mongo allows you to $set two fields on the same document at the same time, for example, and have both writes win, which is very useful and removes distributed locks etc. This is just like updating specific table columns on postgres, but postgres doesn't allow that within columns, you'd have to lock the row for updating to do this safely which is a PITA.
Post reply on HN