1. The fact that one must hack together Meteor with anyting other than MongoDB effectively makes it "tied to MongoDB". Most people who want to engage in this level of hackery in their spare time would, I think, just ignore Meteor and dive straight into some version of the MEAN stack.
2. Because that's the whole point of Meteor: that it doesn't require the same level of server-side savviness and hackery that server-side JavaScript usually requires. Meteor is trying to be something like Rails, where the barriers to entry are not quite so prohibitive for quite so many aspiring developers.
3. Meteor must have official support for one (or more) of the SQL db's in order to take off. That's not all it needs, but it's a big one. I'm interested in seeing how SQL support is implemented, and I assume we're talking some sort of ORM, but we'll see.
Completely agreed. Without real proper officially supported SQL db connectors, I don't think meteor will really take off.
I say this as someone who has used it and like a lot of the features. I just can't see myself taking something to production on mongoDB.
Also, now that the meteorJS codebase is stabilizing, I think it may be time for some conventions to mature around it. Right now, it's essentially the wild west of JS.
Agreed as well, with the one qualifier - "yet". It was not very long ago that Meteor lacked something as simple as authentication and method protections. While it's not clear when some of these features will arrive 100%, they will come eventually through a community-driven effort or through an officially sponsored implementation.
Yeah the lack of SQL db connectors is really surprising for a 1.0 platform; I'm sure it's going to be tricky to implement that so I give them a bit of pass on that front.
The lack of out of the box other NoSQL options is puzzling though because NoSQL db's are a lot close to each other than pure SQL is. And given the general disdain for MongoDB these days, it seems that uncoupling from that dependency would be a high priority. I'm sure there are plenty people on HN that simply won't even give it the time of day because of MongoDB.
You can query data from SQL; just include necessary NPM driver and you're away. It wont be "Realtime" though.
Other NoSQL Support:
The realtime driver is the problem here.
Meteor creates "live queries" by tailing the MongoDB oplog. This works in part because "Minimongo" a javascript based mongo query engine can examine the oplog and determine what does & doesn't match a live query.
To support another NoSQL solution, this huge engineering effort would need to be reproduced.
To support "Realtime" SQL, they'd need to hook in to something like PostgreSQL 9.4's logical replication, and have a javascript based query-compiler & interpreter. (Or provide a mongo-like interface to SQL.) Not impossible, but not easy by all means.
I somewhat agree with the Grandparent (re: Firebase/Parse) - However, I'd like to see the Meteor team have their own realtime database; as the realtime paradigm changes how a lot of it would be built.
MongoDB is notorious for losing data. That alone is a deal-killer, and reason enough to stay away.
The slightly more complicated thing: it isn't even necessary for us to reinvent the database wheel, except for the fact that SQL is hard. Lots of people spend their entire careers avoiding SQL like the plague, which is okay because they have an SQL-ninja down the hall handing them queries to plug into their code. But for a lot of open-source weirdos, that ain't happening, because there's no SQL-ninja down the hall, just more JavaScript hipsters and Rails hippies. So Monongo!
Problem is, it ain't cool to lose your client's data. It's a career disaster. NoSQL is gonna have to get a LOT more robust before most professionals will accept it as a swap-in for SQL.
Lastly, and this is kinda the heart of it for me, is this: data is almost always inherently relational. And we simply haven't come up with anything better than SQL to manage this relationality. Maybe we will, I don't know. Meanwhile, it doesn't take a Bearded Old Programmer to see that there's something a little too bubbly about Mongo and its NoSQL kin.
I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL.
2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server).
To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.
2. Because that's the whole point of Meteor: that it doesn't require the same level of server-side savviness and hackery that server-side JavaScript usually requires. Meteor is trying to be something like Rails, where the barriers to entry are not quite so prohibitive for quite so many aspiring developers.
3. Meteor must have official support for one (or more) of the SQL db's in order to take off. That's not all it needs, but it's a big one. I'm interested in seeing how SQL support is implemented, and I assume we're talking some sort of ORM, but we'll see.