Can I use MongoDB as a replacement for CoreData on iOS?

Question

I'm just starting to read up on NoSQL technologies such as MongoDB and CouchDB. I'm interested in knowing whether I can use MongoDB or indeed any NoSQL technology as a replacement for Core Data applications.

Core data applications can take a long time to learn and implement, especially if your app is complex and you just want to do some simple add, edits, deletes and queries (CRUD stuff).

Because it looks like JSON and looks like it can run really fast; I'm interested in the implementation of NoSQL over Core Data.

Can I run MongoDB as native? I did some Google searches but wasn't really able to get the specific answers I'm after.

Such as:

I am not sure what the remit is for NoSQL on iphone platforms, is it supported, would it be denied by the Apple team if I submit an app with NoSQL on it?

Thanks

Solution 1

As an aside, I will note that it's a common misperception but Core Data is not a database system.

Instead, it is a runtime object graph management system with persistent tacked on as option if you want it. It's primary function is to provide the model layer of the Model-View-Controller design pattern. As such, it deals with a lot more than just getting data on and off a disk.

Core Data does have a learning curve but in my experience the biggest obstacle many face is trying to treat Core Data as some kind of object oriented wrapper around SQL. From that perspective Core Data is very confusing because it seems to require to learn so much that has nothing to do with persistence.

Using database like SQLite, MongoDB and CouchDB for persistence won't really speed things along at all because, although you might better understand how they get data on and off the disk, they won't help at all in managing the data and the relationship to the other data objects and the objects of the UI. You still have to have a data model and you will have to code all that up by hand. Unless your data model is extremely simple, that will take more time than learning Core Data.

The best way to learn Core Data is to ignore the fact that the object graph can be persisted at all. Just start from the perspective that you've got a lot of objects that represent the data model of you app and you have to manage their attributes and relationships.

Solution 2

MongoDB is probably not a good fit here. The server assumes that disk space is not a limiting factor. The current stabel brance (1.6.x) does not provide data durability on a single instance. It also uses memory mapped files which are fine on dedicated servers but will cause lots of disk churn and unnecessary memory use on a typical PC. I have no experience with Core Data, but it sounds like a septate niche to me.

Solution 3

MongoDB is not designed to be used as an embedded database. It is designed for speed and scalability and unlikely fits the architecture of an embedded OS like IOS. However talking to some MongoDB-backed service in the "cloud" through standard protocols like HTTP/S should not be an issue. You just need to write some web-gateway in front of MongoDB.

Solution 4

I know that this is a really old question, but I thought I would offer an answer anyway. Couchbase has a suite of software called SyncPoint, which includes TouchDB, which is a build of CouchDB built to run on iOS natively and synchronize itself with any Internet accessible CouchDB instance.

Solution 5

CouchDBX http://www.couchone.com/get is a Cocoa application that bundles CouchDB into an OSX app if that is what you are looking for

View more solutions

Comments

[BoltClock]

Core Data is not a database. Theoretically one could use Core Data with NoSQL.

[james]

core data doesn't take long to learn! i find it quite easy once setup

[Bernie Hackett]

mongod is a server. Correct me if I'm wrong but Apple isn't going to allow you to install mongod with your application.

[zardon]

Okay, thanks for your help. I appreciate it.

[Coyote]

Your question is pertinent. There are times you will rather use a different Data format/storage than the one provided by the platform's SDK. In that case there are embedable databases (libs or source) you can add to your project. There are drawbacks, but at least you can port your application to other OSes if the DB and the app are written in C/C++. Concerning NoSQLs there are probably some solutions out there.

[Admin]

Why not use the REST interface on MongoDB and make REST calls via NSURLRequest.

[sweetiewill]

Couchbase Mobile rather would be the consideration here for a replacement of Core Data

[Mohammad Abdurraafay]

I believe Core Data + DB (SQLlite) = NoSQL!!

[TechZen]

No, not really. NoSQL is about structured storage. Storage is an afterthought in Core Data. See this related answer about when to Use Core Data stackoverflow.com/questions/5237943/…

[TechZen]

The larger and more complex the data, the better a solution Core Data is.

[Chris Wagner]

Great way to look at it @TechZen

[Maury Markowitz]

I'm sorry, but I disagree. Document DB's exist precisely to solve this problem - directly storing complex graphs WITHOUT having to to any management. You simply make your objects any way that makes sense to you, and save them. And if this objects change, just change them, it will have no effect on the store. CD is a nightmare when it combines persistence AND changes.

[TechZen]

@MauryMarkowitz - Possibly, but how about other features like migration of models and data, parallelism, cloud syncing, long term backing from an Apple equivalent etc? I don't think anything really combines all the features top to bottom available through Core Data. But that feature set is the cause of the steep learning curve. Core Data is a huge API because it does so much. I have not found anything that can actually replace it completely especially in terms of being able to upgrade and scale. Neither can any other technology assure it will always be supported going forward.

[TechZen]

@MauryMarkowitz - 1) e.g. Realm (Realm.io) show promise. It's easier to learn, get running, cross platform vis iOs and Android but still does not have near the feature set of Core Data. e.g. its mobile only so if you want a Mac/PC to mobile app, it can't help. Most alternatives I have checked have about 80%-90% of what I need for any given project, usually some really strong benefit, then a deal breaker. Even if I found one good fit for one project, I would still have learn a new API. 2) My main point originally was to not think of CD as an SQL wrapper. That still holds.

[TechZen]

1) Having said all that, I'm pretty nose down in the Apple ecosystem so no one should take my answer about alternatives as anyway definitive. Its so easy for me to work in CD I don't devote a lot of energy to alternative research. 2) In any case, for the small independent developer, the iron law is always pick the tech that will allow you ship, if don't ship nothing else matters. If learning CD is going to so bog development you can't ship and/or you already know another API use it in most cases. You have to ship before you can worry about upgrading features or scaling.

[sweetiewill]

Couchbase Mobile is very much alive and being used in mission critical use-cases. Can see this article for reference: couchbase.com/nosql-resources/presentations/…

[ngb]

In 2021 Crud is literally 2 lines in core data. There isn’t another solution out there that can do that. Yes it takes time to change your brain to think in core data but it’s the fastest way to get a data based application up and running.