[SonnyWortzik]

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 your post because they liked what they saw at the time, exposing you to the world where everyone now thinks you have something important to say. Not surprisingly, you don't!

[mmsimanga]

I don't have any links to prove my point but I suspect we need to thank Mongo for pushing the traditional SQL databases to support JSON.

[WorldMaker]

I think the fact that the Cosmos DB "document db" API clones the MongoDB API, of all the available options, is a link in that chain.

[zorga]

Why? Seriously, JSON is lame, it's an idiotic trend, a fashion from the UI that's infected the back end for no gain whatsoever for anyone not using JavaScript. XML is better and we've just watch JSON slowly reinvent everything XML already had.

[Too]

I think he meant json as a data model, ie nested objects, arrays and PODs, rather than json as a textual representation..

[ddebernardy]

FWIW and insofar as I can recollect, JSON was supported by Postgres before Mongo was a thing, and Mongo was built based on Postgres.

[anarazel]

No, that's not correct: Initial json support in PG was added in early 2012 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... whereas mongodb was made public in 2009, according to wikipedia: https://en.wikipedia.org/wiki/MongoDB

I don't see how Mongo was built based on Postgres, either?

[ak4g]

My guess is the grandparent is (mis-)remembering the kerfuffle[0] around mongo shipping a copy of PG as a "BI Connector". But yeah, the timeline is off, that was in 2015.

0: https://news.ycombinator.com/item?id=10697692

[ddebernardy]

Actually, no. I'm remembering asking myself how Mongo worked back when it launched, and reading somewhere that it was a heavily modded Postgres under the hood (like Amazon Redshift, which makes no secret about it, since).

I might be misremembering, though. And there's a possibility that what I read then was inaccurate.

[ddebernardy]

I might admittedly be remembering this wrong, but I seem to recollect that Postgres had a couple of (unofficial) contrib modules to support JSON back in 2008 or so, and that (unfortunately buried in Postgres vs Mongo articles) the initial release of Mongo was actually a fork of Postgres for all practical intents.

The relevant data structures and indexing mechanisms (hstore, tsvector, gin, gist) were all available -- if only experimentally -- before Mongo launched.

[vonseel]

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.

[BuckRogers]

SSRS is a big draw. There are other and probably better reporting tools, but the integration and support from MS is worth something to most companies. There's also simply the network effect at play and marketing, that MS has always backed that up with results. The money involved really isn't prohibitive for most small to mid-size companies that I've worked with. I've only seen the opposite, companies leaving their expensive UNIX licenses to move to an all-MS stack to save money. I have never seen large companies try to reduce their technology costs to zero with pure open source, because I think they intuitively know that you either pay with your licenses or you pay with maintaining a lot of expensive expertise, that also needs properly managed and effective. In the discussion of free as in freedom vs free as in beer, most companies core business is not technology, and they know there's no truly free beer and don't really care about the freedom. They want everything I've already mentioned, and the short and longterm support the license buys.

Outside of my professional career, with my personal projects I use SQLite, but if I were to build out something that intended to be larger scale business venture, I'd probably go with Azure SQL Database for multiple reasons. A large one being MS's overall integration, including their full control of the stack and CI/CD with .Net->Azure DevOps->github->Azure Pipelines->Azure PaaS/SQL Database. I admire what they're building, but a lot of people work outside of the MS realm. Companies don't tend to have a tech stack bone to pick as we do on HN, and many are already using part of the MS stack.

In sum, there's just a lot of business realities at play. I wouldn't personally run out and buy a SQL Server license myself, for what I do at home or with my (very) small side business, either.

[SonnyWortzik]

Integration. It is all about the integration. M$ platform is so tightly coupled that many companies see the value in spending on this tight integration than spending it on 25 different Engineers to manage their 40 vendors that may be needed to run some of these applications and platforms.

Dealing with one vendor, M$, is better than dealing with 20. You pay for one support package and get all the benefits that come with one platform.

As much as I love open source, I do see the benefit of working with one vendor on all of your stack needs.

M$ reporting systems of SSRS SSIS and other is probably their bread and butter when it comes to DB space. Very few want to spend 60-70 hours a week building complex command line reports where with SSRS and SSIS most of these tools come with a nice GUI that helps you build these reports. Sure there are others that do the same but most required a third party vendor to add to the functionality. For example Apache. With Java and Apache I've had to deal with literally 15 to 20 different vendors just to do the same thing I can do with one vendor. Jenkins, Zookeeper, Camel, Cassandra, Tomcat all under the banner of Apache, but in reality governed by their own set of standards. I mean take a look for your self: https://www.apache.org/index.html#projects-list

[magduf]

>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.

[vonseel]

Understood, but I should have prefaced my question with “for greenfield / new development”.

[magduf]

My answer is still the same, and actually assumed that. No one is really "greenfield": everyone is already invested in some technology to some extent. If your organization is already invested in MS technologies, your managers only know MS, and your developers only know MS/.NET/etc., then the choice is pretty obvious: MS SQL Server. Switching to Linux/PostgreSQL would be a sea change for an organization like that (even though, IMO, it would be better in the long run).

Similarly, if your organization is already a Linux-based one, running Linux servers for everything, adopting SQL Server would be a huge PITA and would likely be laughed out of the room if suggested.

[mey]

I really like SQL Server, especially the dev environment, 1st and 3rd party management tools. Not sure if they have improved this, but replication was a limiting factor and the pricing changes a few years back pushed it down my preference list.