Or a third client type: one who is using another database, and they have no interest in changing.
There have been many suggestions of other databases that would work great with Meteor, but only two of those even shows up in the top 10 databases used by real companies: MongoDB and PostgreSQL. Maybe I’m just old-school, but I’ve worked for half a dozen Fortune 500 companies in my 20 year IT career, and selling management on implementing something new would be next to impossible. Here’s the ranking: DB-Engines Ranking
So for me, which database to use is a pointless question. The only question that matters is “does this platform support the database engine that my client uses?”
Sure, it would be possible to build a stand-alone system that uses another system and then build an ETL process that syncs data up as needed, but again, that would be a hard sell.
The missing piece for Meteor is a universal DB driver that works with pretty much anything, at least anything that has a good well supported Node driver out there. Tying it to a specific DB was a huge mistake, IMO. MGD realized recently that adding other front end frameworks like React and Angular would be a good idea, and I like that. They need to do the same for a universal DB driver. The ccorcos:any-db package looks interesting, I’ll have to give it a try.
Hey @waldgeist!
Unfortunately we haven’t found the time to write up a complete documentation yet. Currently the best way to get a feeling how to use the package is to take a look at the integration test which covers the basics:
But there is something big coming soon: We are building a clone of this excellent CQRS tutorial that will explain all important concepts and cover the important packages of the meteor-space framework (it’s not just event-sourcing ;-)) Our plan is to use the Meteor Global Hackathon to flesh out a nice UI too, so it’s not just boring business concepts.
Of course we are already using this package in production and are constantly refining the patterns / adding important features! If you want to join the discussion or ask any kind of questions, join our Gitter chat. We are a currently building a small but very friendly community around the Space framework
In what way was this at all useful? No-one here is talking about any / many schemas, they’re talking about data reliability and the perception of MongoDB. That package (which is very good, I might add) does nothing to support either argument.
It’s like you jumped in on a discussion about what everyone’s favourite sandwich is by saying you love McDonald’s…
As a casual observer, thread seems a bit reactionary. Rather than addressing the problem of broader effect on the marketability of Meteor due to it’s coupling with Mongo, everyone seems to just be arguing tenets of Mongo itself.
Shouldn’t Meteor transcend the preference for Mongo? Last time I checked out Meteor, there was supposedly active development in removing the need for Mongo. I guess the tone just has kind of an echo-chamber feel to someone interested in Meteor but wary of Mongo. Is Mongo really a sword worth falling on for Meteor?
@SkinnyGeek1010, I’m almost done with a new version of AnyDb. I’m using it with Neo4j right now and its working great, but you could just as easily use it with any other database. I’ll release it in the next couple weeks.
I really wish accounts-base was written in a more generic way so I wouldnt be stuck using Mongo for accounts, but we’ll tackle that later.
I think a big reason is that its tough to get out-of-the-box reactivity from a relational database. Because mongo is non-relational, computing observeChanges based on the operation log is a challenging but tractable problem. On the other hand, reactivity in a relational database isnt so easy. Here’s an example I’ve been dealing with: Suppose a user’s feed consists of posts that people they follow have starred. In Neo4j, the query looks like this:
MATCH (:USER {name: 'Chet Corcos'})-[:FOLLOWS]->(:USER)-[:STARS]->(p:POST)
RETURN p
Now suppose someone stars an event. Its not so trivial to know if this user’s feed needs to update. You actually have to run a query to determine if ‘Chet Corcos’ is following that user.
So if Meteor is going to support other databases, its going to require that developers put a little more legwork into computing how changes effect queries…
I do wish they would have implemented other non-relational dbs by now (like CouchDB, Redis, Rethink, Cassandra) with poll + diff (even if they had to hire an additional team that did nothing but this).
On the other hand, reactivity in a relational database isnt so easy. Here’s an example I’ve been dealing with: Suppose a user’s feed consists of posts that people they follow have starred. In Neo4j, the query looks like this
Thanks for providing that example! It’s really interesting to see the challenges that lie ahead.
I’m loving AnyDB, keep up the good work!
As a side note, I was wondering why nobody ever mentioned TokuMX as a replacement for the standard MongoDB where ACID and transactions are needed. Has anyone any experience using it with Meteor?
Did you take a look at OrientDB? It’s really promising.
You can get a document graph db supporting transactions - ACID. I don’t know if the Meteor OrientDB package is production ready though.
FWIW I’ve been using the 1.6 release builds since the first alpha was put out with node 8, it’s all been going smoothly. If you’re not in production yet, give it a shot
