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?
Bye Bye Mongo, Hello Postgres
211–220 of 427 posts
Re: Bye Bye Mongo, Hello Postgres
#212I 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…
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
#213Earlier 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.
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
#214My 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?
Re: Bye Bye Mongo, Hello Postgres
#215Earlier 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 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
#216Earlier 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.
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
#217Earlier 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…
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
#218I 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…
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
#219I'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…
Re: Bye Bye Mongo, Hello Postgres
#220While 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.