-
Notifications
You must be signed in to change notification settings - Fork 301
FAQ
- What Is This?
- Performance & Size
- Compatibility
- Implementation & Design
- Choices, Choices
A: To quote from the Why Couchbase Lite? document: “Couchbase Lite is a lightweight CouchDB -compatible database engine suitable for embedding into mobile apps. Think of it this way: If CouchDB is MySQL, then Couchbase Lite is SQLite.” For more details, read that page.
It was originally known as TouchDB. In January 2013 we changed the name to Couchbase Lite to tie it in with Couchbase’s branding. The original 1.0 release of TouchDB has kept the old naming, but the newer releases are known as Couchbase Lite.
A: The reference Objective-C implementation runs on iOS 5+ and Mac OS X 10.7+. There is a Java port for Android devices, but it’s less mature.
The Objective-C implementation was partially adapted to run in the GNUstep environment, which makes it portable to Linux, BSD, Solaris, etc. and even Microsoft Windows; but it hasn’t been built or run in that environment for a while, so there would certainly be more work to do to bring it back up to speed.
A: It’s passed the 1.0 milestone, and the released versions are ready to use in apps. As with any open source project, the latest commits do represent “bleeding-edge” functionality and should be usd with caution.
A: There’s a Grocery Sync app for iOS that implements a simple checklist that can sync with a server.
A: Couchbase Lite itself is released under the Apache License 2.0 (the same as CouchDB and Couchbase Mobile.)
Some libraries that Couchbase Lite uses (FMDB, MYUtilities, and CocoaHTTPServer) have MIT or BSD licenses. We may seek relicensing or rewrite those parts of the code, to get everything under a single (Apache) license.
A: Couchbase. The coding so far is by Jens Alfke (snej), with Marty Schoch handling the Java version, and some contributions by awesome volunteers.
A: Yes; you can see a list on the “Couchbase Lite In The Wild” page.
A: Sure — the Google group is the best place. (You can access it on the web or subscribe to it as a mailing list.)
A: Right now (January 2013) it compiles to about 400k bytes of optimized ARM7 code.
A: About 100ms to initialize the library and open a small database. That’s a cold launch; if the app has been launched and quit recently, leaving stuff in cache, it’s more like 60ms. This is on an iPad 2; older devices will be a bit slower.
A: Fast enough for the kinds of data sets mobile apps would be expected to use. It’s effectively instantaneous for small data sets. It won’t handle big data as well as Couchbase Server or CouchDB, but it keeps up pretty well with tens or hundreds of thousands of documents. And it doesn’t mind arbitrarily large binary attachments; those are kept as files in the filesystem.
A: There aren’t any hard limits in Couchbase Lite itself, nor to my knowledge in SQLite. The most likely practical limit is the available disk/flash storage on the device, and of course app responsiveness as query times increase (see above).
I’ve heard that Android has a 2GB file size limit; but this should be less of a problem for Couchbase Lite than CouchDB, because the database file doesn’t grow as fast (it doesn’t need explicit compaction) and because it doesn’t store attachments inside the database file.
A: In the ways that matter, yes. The REST API is compatible, although you talk to the engine in-process rather than over a socket. Some of the more server-centric features of CouchDB, like user accounts, aren’t supported.
A: Yes, its replication protocol is entirely compatible. That’s a very important goal. Apps using Couchbase Lite can sync with servers running Apache CouchDB or BigCouch, and with hosting services like Cloudant and IrisCouch.
A: Couchbase Server 2.0 uses CouchDB technology but has been heavily customized to optimize performance. As a side effect it no longer replicates with CouchDB, or therefore with Couchbase Lite. This is obviously an issue! We are working on a technology called the [Sync Gateway](https://github.com/couchbaselabs/sync-gateway) that will act as a server-side bridge between Couchbase Server and mobile clients.
A: Yes, the fundamental data model is also compatible. That’s pretty much required for replication compatibility, anyway.
A: Yes. Revision trees are implemented, and preserved across replication.
A: Yes, although for size reasons it doesn’t include a JavaScript interpreter, so views are implemented in native code (e.g. as blocks in Objective-C.) The same goes for filter and validation functions. (It’s possible to use JavaScript-based functions if you’re willing to link in some extra code and libraries.)
A: Pretty much. Couchbase Lite has its own native API, but there’s a REST adapter that understands standard CouchDB requests. The iOS implementation registers a custom URL protocol handler with the CFNetwork framework, which means that when the app uses the Cocoa NSURLConnection API to access “cbl:” URLs, it talks to the Couchbase Lite library in-process instead of to the network. There are no actual sockets involved at all. This makes it easy to adapt code that talks to CouchDB, such as CouchApps.
A: There’s an experimental HTTP server extension called CouchbaseLiteListener. It’s mostly there to enable Couchbase Lite-to-Couchbase Lite (P2P) replication as well as making testing easier. It’s not meant to be the primary way for an app to access Couchbase Lite.
A: Couchbase Lite doesn’t currently support every detail of the CouchDB REST API. We’ll add support for things that turn out to be important to mobile apps, and will probably ignore things that aren’t (like /restart, /_config and /users.)
Other things that aren’t compatible: The database file format. Configuration options (no .ini files.) Functions in interpreted languages (JS or Erlang). List and show functions.
A: CouchApps running in PhoneGap are definitely an interesting mobile platform. We have a TouchGap project in Couchbase Labs showing how to combine Couchbase Lite with PhoneGap.
A: It wasn’t possible to optimize CouchDB’s size and startup time enough for mobile apps. We were able to get some significant improvements in Couchbase Mobile 2.0, but beyond that, further shrinking and speeding-up possibilities seemed pretty minor (on the order of 5%) when what we wanted were orders of magnitude. Most of this was intrinsic in the fact that it’s implemented in an interpreted language (Erlang) whose runtime library needs to be bundled in.
A: The design is cross-platform. After considering various interpreted languages and cross-platform libraries, I decided they had too much overhead for mobile apps, or would make the implementation too awkward. So instead the goal is to have separate implementations for each platform, but share aspects like the SQL schema, class architecture and algorithms.
A: True, from that standpoint it might have been better to start with a Java implementation for Android, since more people read Java fluently than read Objective-C. In the end it came down to the fact that I (Jens) like Objective-C better than Java, and have experience developing for iOS but not Android.
A: Yes, my colleague Marty Schoch has been working on a port of my implementation. It’s also on GitHub.
I have heard interest in an ANSI C implementation (possibly using the Apache Portable Runtime or GLib) but to my knowledge no one is working on one yet. It’s not unlikely that Couchbase will develop one, since there may be customer interest.
A: No. I am honestly not very familiar with the CouchDB implementation. I don’t think it would have made sense to refer directly to the Erlang code anyway, as the way code is structured in that language (functional, highly parallelized, non-OOP) is very different from imperative OOP languages like Objective-C and Java.
And in any case, a lot of the code is of necessity very different because it’s using SQL for storage, rather than a custom append-only B-tree implementation.
A: No, it lets SQLite take care of file storage and indexing. Couchbase Lite database files are regular SQLite databases. There’s documentation on the schema, if you’re curious.
A: Largely because SQLite is already available as a shared library on every platform we’re interested in; this keeps our code size down and simplifies the build process.
Additionally, both Berkeley and Kyoto have GPL-like licenses that are less friendly to commercial developers (especially iOS developers) and incompatible with the Apache license of Couchbase Lite itself.
A: Because it’s a lot smaller, starts up a lot more quickly, and is easily embeddable into an app. Those are important factors for mobile app developers (and some desktop app developers too.) If you’re working on server-side software they probably don’t matter to you, or at least don’t outweigh the drawbacks.
A: Because CouchDB is more mature, scales better, interoperates easily with other server processes using a REST API, and runs on more platforms.
A: World-class, highly-flexible data sync capabilities that go way beyond what you can get from iCloud. Another factor is that the API is (we think) simpler and easier to use than CoreData’s.
A: As with the previous comparison to CoreData: the big reason is sync. If your users want to work with their data on multiple devices or platforms (including the Web), or have it transparently backed up, the replication capabilities in Couchbase Lite and CouchDB will make it very easy compared to the pain of implementing sync yourself, or trying to duct-tape your custom SQLite database to the iCloud APIs.