Earlier quoted context omitted.
A) Postgres easily scales to billions of rows without breaking a sweat. After that shard. It’s definitely negotiable.
So does a text file. Statements like yours are meaningless when you aren't specific about the operations, schema, access patterns etc. If you have a single server, relational use case then PostgreSQL is great. But like all technology it's not great at everything.
MongoDB acquires Voyage AI
111–120 of 172 posts
Re: MongoDB acquires Voyage AI
#112How does MongoDB still have that much available to spend? Everyone I know moved off it years ago.
Re: MongoDB acquires Voyage AI
#113Earlier 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.
If learning SQL is hard, maybe software isn't the best choice of career. Writing code and creating good software requires a lot of mental clarity and effort; that fact is never going to change, not even with AI.
Firebase by and almost every NoSql technology is based upon this.
Re: MongoDB acquires Voyage AI
#114Earlier quoted context omitted.
The use a text file. In all seriousness, calling Postgres’ scalability “not-negotiable for most use cases” is wild.
What's wild is you misrepresenting what I said which was: "built-in, supported, proven scalability and high availability" PostgreSQL does not have any of this. It's only good for a single server instance which isn't really enough in a cloud world where instances are largely ephemeral.
Re: MongoDB acquires Voyage AI
#115Earlier quoted context omitted.
Mongo is real distributed and scalable DB, while postgres is single server DB, so main consideration could be if you need to scale beyond single server.
High availability is more important than scalability for most. On average an AWS availability zone tends to suffer at least one failure a year. Some are disclosed. Many are not. And so that database you are running on a single instance will die. Question is do you want to do something about it or just suffer the outage.
Re: MongoDB acquires Voyage AI
#116Earlier quoted context omitted.
> MongoDB ships with horizontal sharding out-of-the-box Maybe it's better than it was, but my experience with Mongodb a decade ago is that that horizontal sharding didn't work very well. We constantly ran into data corruption and performance issues with rebalancing the shards. So much so that we had a company party to celebrate moving off of Mongodb.
> my experience with Mongodb a decade ago So before the Apple Watch was released. Why is this relevant today ? Technology changes very quickly.
Re: MongoDB acquires Voyage AI
#117Genuine 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?
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.
Re: MongoDB acquires Voyage AI
#118Genuine 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?
Re: MongoDB acquires Voyage AI
#119Earlier 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.
Even as a JSON document store I'd rather use postgres with a jsonb column.