Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

211–220 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#211
post #68

Earlier quoted context omitted.

I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. MongoDB was the natural choice because they excelled at being accessible to devs who were already familiar with Javascript and JSON. Not only that, their marketing/outreach efforts were also…

> When was the last time you saw a Postgres rep at a college tech event? Is a Postgres rep a thing?

I remember a hyperbolic readme or other such txt file for Postgres in the far-away long-ago time when everyone was on Slashdot. The author had written one of the most enthusiastic lovenotes to software I'd ever read, and that includes Stephenson's "In The Beginning Was The Commandline." It was a Thomas Wolfe level of ejaculatory keenness. I'd love to read it again if anyone else knows where I can find the file. So, even if there aren't actual Postgres reps, there are most assuredly evangelists.

Re: Bye Bye Mongo, Hello Postgres

#212

I never got around to using Mongo as my main doc db because it was incredibly hard to find a management tool. I now use json supported functions in SQL Server and do not have the need for a different type of database. SQL Server handles my small 'documents db' implementation with the infrastructure of a RDMS. Win win for me. To me Mongo just got popular by mistake way too early. It's like having a celebrity retweet y…

I have seen so many critical articles of Mongodb. Even if I did have a use-case particularly well-suited for it, I would never consider using Mongo.

As an aside, I did consider using SQL Server until I looked at the licensing fees. Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Is there a specific SQL feature (MSSQL or Oracle SQL) provides which is not available elsewhere and would be a core feature which the companies data storage is built upon? I.e. that feature is so important that the companies product architecture would be fundamentally different without using the proprietary database.

Re: Bye Bye Mongo, Hello Postgres

#213

Earlier quoted context omitted.

Well, we're kind of comparing MongoDB of ~2011 (when The Guardian started using them) with Postgres of today. One major change is that in 2010 you couldn't always run your whole DB in RAM, so there were some real performance benefits with MongoDB. Another difference is that MongoDB was early with great JSON-support. Something that Postgres has since gained. I think there are pros and cons with both. If I'd chose one…

If somebody is teleporting back then, the fact Mongo had a _global_ Mongo instance level lock for writes should be more than enough for people to run screaming. I worked with databases that only had table level locks(not row level) and there were more than enough occasions I cursed the creators. Instance level(& indeed DB level) is insanity unless your DB is a read only DB.

Not saying you're wrong, but a news site and CMS has different database requirements than many other products.

They have very few write actions; in the Guardian's case hundreds of authors publishing a few articles a day, versus millions of users reading data. Writes would be sporadic and batched.

News products also changes more rapidly than you might expect. A modern news team may be writing and shipping code to better cover a breaking news event. I can imagine why a document store would be appealing to them.

Re: Bye Bye Mongo, Hello Postgres

#214

My takeaways: 1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas. 2. There's no such thing as hassle-free anything, unless you are paying someone else to deal with the hassle. Sales teams lie. 3. Justifying an untested idea with "but it's modern technology" is going to backfire. Follow established patterns with good track records. 4. Writing your own in-house beh…

Point 5. I'm not a software/application person... can you expound on how else you would interact with a DB if not directly?

I'm pretty sure he wants to say that you should abstract your database away so that your business code / domain model doesn't depend on it. It becomes a "plugin" to your application and you can easily switch it just by writing another implementation.

Re: Bye Bye Mongo, Hello Postgres

#215
post #53

Earlier quoted context omitted.

What really happened is people wanted something new but did not want to change the ways they DESIGN their application and processes. There is place for NoSQL but if you are going to use it as if it was SQL then you would be better served by an SQL database. Also, I think MongoDB tried to be everything and failed to be good at anything. It offers neither stellar performance nor scalability and I guess for most project…

Just a few thoughts. A lot of little companies like picking hyped tools because they think it will differentiate them and server them well later, but most companies never get to that stage and don't really need what is being offered. Seems much safer to take the tried and true standard solution that has worked for decades and just make your UX outstanding rather than try to put together a "dream team" of new tech...

Another thought. Most companies have absolutely no idea how to select the technology. A lot of people that are in position to decide don't have all that much hands on experience with the new technology and so they will decide based on other factors like whether his manager would like or would like not see new technology, what other companies are doing, etc.

Another example is "Agile". Everybody is doing it yet I still wait to see a single company that understands what the term means. My current boss is big promoter of "Agile" which in his language is synonym to "Scrum". Yet when asked he has never heard of Pheonix Project, The Goal, theory of constrains or basically any theory at all. So what the people are doing is fighting fires almost 100% of the time with not much project work done for the effort and absolutely no improvements. Yet, because everybody complies to do daily standups and Jira updates we are 100% agile.

Don't even get me started on devops...

Re: Bye Bye Mongo, Hello Postgres

#216

Earlier quoted context omitted.

It's amazing how many insurmountable SQL performance problems can be surmounted by putting things in 3rd normal form.

But denormalization is one strategy to improve the performance of a rdbms.

It's not, it's a strategy to improve the performance of a particular query or access pattern, and is usually the last resort after things like proper indexing, aggregations and materialized views.

JOINS are fast and it all comes down to how much data you're moving. If it's a large table joining to a small set of values, then the joined data is quickly retrieved and applied to the bigger table, with great performance.

If the join is between two large tables where every combination is unique then that's the unique case where the joined table is just adding another hop to get the full set of data for each row and is a perfect candidate for denormalization, although in that case it probably should've been a single table to begin with. Of course there's a spectrum between these two scenarios but it takes a lot before denormalization makes sense on any modern RDBMS.

Re: Bye Bye Mongo, Hello Postgres

#217
post #48

Earlier quoted context omitted.

Those companies did not create PG, the company behind Mongo did and does not want Google / AWS / MS to make a service using Mongo for free.

I'm glad that RedHat didn't feel that way when they were sponsoring kernel development, or that Netscape had panicked and locked down Netscape instead of opening it up, or that Sun had given Java a terrible license. Or Google and Kubernetes. LinkedIn and Kafka. Airbnb and Air Flow. I could keep going like this all day. Mongo made a lot of money building a projects that runs on top of many other projects that were rel…

So Redis, HAproxy, MongoDB, ect .. should feel good that nowdays multi-billion $ companies take your product and put more people on it that you do internally, sell it and give you nothing?

Explain to me how a startup of 10-20 people can compete against AWS once they grab what you're working on to make an AWS service?

Changes Mongo, Redis made to their licence were made to protected against those practices.

Re: Bye Bye Mongo, Hello Postgres

#218

I never got around to using Mongo as my main doc db because it was incredibly hard to find a management tool. I now use json supported functions in SQL Server and do not have the need for a different type of database. SQL Server handles my small 'documents db' implementation with the infrastructure of a RDMS. Win win for me. To me Mongo just got popular by mistake way too early. It's like having a celebrity retweet y…

I have seen so many critical articles of Mongodb. Even if I did have a use-case particularly well-suited for it, I would never consider using Mongo. As an aside, I did consider using SQL Server until I looked at the licensing fees. Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Is there a specific SQL feature (MSSQL or Oracle SQL) provides which is not available elsewhere and w…

>Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist?

Because they're in an organization where they're already invested in Microsoft technologies, so it's much easier to just use MS's DB instead of something entirely different that doesn't integrate as well.

It's similar to why many people use Apple software products that aren't as good as alternatives: if you already have an Apple platform/device, it's easier and better integrated and likely already installed.

Re: Bye Bye Mongo, Hello Postgres

#219
post #112

I'm not sure why a database is required at all. Surely the main advantage is to support tables and joins. If you just want a key-value store surely S3 or similar would be simplest. Do they search the data? Surely Cassandra is designed for this. Any ideas?

Cassandra isn't designed for this. Been there, done that. postgres all the way. THe FT use(d) cassandra to store their membership details (6 million rows of largely static, read-only well structured data) The cluster was massive (12+nodes in at least two regions, from memory) slow and was impossible to upgrade reliably. The support from datastax is shite. Backups are not reliable. imports even less so, and you are be…

What were the issues? You're the first person I hear complain about cassandra for this. Agreed that any database can do that type of data at that volume.

Re: Bye Bye Mongo, Hello Postgres

#220

While we are here. I know HN hates mongo. But lemme ask this question, what are the things in which mongo is better than postgres?

mongo is shared nothing architecture, which can linearly scale data-wise, postgres is not and can't.

bullshit. It's shared everything. if you have a 3 nodes cluster for redundancy, the 3 nodes keep the exact same data with only one node accepting reads and writes. It's literally the opposite of linear scalability.
Post reply on HN