Congratulations on the funding. But the "the 2nd-most deployed database in the world in less than a year" is a little... I don't know. If a popular app decides to use your database, shouldn't you count that as 1 installation instead of taking the number of people that will download the popular app? The comparison doesn't seem fair for non-mobile databases. I would rewrite it as "the 2nd-most deployed mobile database in the world in less than a year".
Alexander from Realm here. I agree that deployments are not the only (or even nessesarily most interesting) metric of usage. But it is a good example of how remarkable mobile growth is. At this point there are just crazily many more mobile devices out there than there ever was on the backend and server side.
It is an interesting metric for us, given that sqlite has for a long time (rightfully) claimed to be the most widely deployed datebase in world, which is also primarily based on their usage on mobile devices.
I've used it in a couple of small Android apps. Overall, I wouldn't recommend it (yet) for anything more than toy projects. The sibling post mentioned a few reasons why, but here's are another few:
No inheritance.
No nested transactions.
No RxJava support (due to threading issues with Realm).
Many annoying random errors (for example, get a row then close the DB connection -> You can't use those results after. Although I believe that this is by design because Realm doesn't cache any data - it queries every time it's requested AFAIK).
It's definitely on the way to being an awesome asset, but it's not there yet!
Yeah we absolutely have a lot of work ahead of us (as mentioned in the post). And the issues you mention are tracked in https://github.com/realm/realm-java/issues. There you can also see that we got a lot more features we want to add than the few you mention :-) We strive to be very transparent about our limitations (http://realm.io/docs/java/0.80.0/#current-limitations) so that they at least don't surprise anyone.
We seriously love to get the feedback so we can prioritize the additional features our users desire the most.
That said, we are very encouraged to see that the current features satisfy a lot of "non-toy" apps as well and that many thousands developers are building new apps every week.
You can see some of them mentioned here: http://realm.io/users/, and at the end of that page is also some unedited interviews with developers.
Hi. I'm using it for the dictionaries in my Custom keyboard for iOS - Type Nine[1], and for the small amount of settings the app has.
It basically provided everything i needed out of the box, and i have dictionaries with 250,000 - 400,000 words that returns BEGINSWITH queries sorted by most used words faster than anyone would be able to type. (below 20ms on an iPhone 5)
I had actually implemented everything in CoreData (sqlite) at first, but when i fell over Realm i gave myself a couple of hours to test it out, and haven't looked back since.
It has a really small API surface, so if you're considering to use it I would definitely recommend you to try it out, it wouldn't take a long time to find out if what you need is available.
Disclaimer: I presently work for Realm. However, what I've written here is based on the opinion I formed in the time I spent using the product before I joined the company.
---
I've been working on a comic reader app for iOS for about 3 years (http://icomics.co). Up until last year, I was using Core Data to persist both metadata information for each comic, as well as per-page caching information to disk.
Unfortunately, Core Data hit a breaking point with me (I encountered a rather catastrophic data corruption issue when trying to get it to perform automatic schema migrations :( ) and, initially as a feasibility test, I decided to try migrating the whole solution over to using Realm. If it wasn't up to the task, my backup plan was going to have been moving to raw SQLite (and all the boilerplate code that that would have required).
Suffice it to say, I was more than impressed with Realm. Since it more or less followed the same objects model as Core Data, porting my apps entire data implementation over to it took less than a single evening of work. The API was ridiculously easy to learn, and I found it much easier to pass data between threads than what I was needing to do to achieve the same result in Core Data. It was also VERY satisfying deleting giant swaths of Core Data code. ;)
I was so impressed with the whole process that after that, I held a talk on it at a local iOS meetup in my city. Afterwards, I uploaded the talk as a video to YouTube (https://www.youtube.com/watch?v=cGptaE2_WEQ) and it was thanks to this video that Realm found me, and how I joined the company. :)
Realm's been in production use in my app for 5 months now, and I can safely say it's performed above and beyond my expectations. For iOS projects, I definitely recommend it. :)
Christian from Realm here. Actually there is no technical limitation that prevents Realm running on normal java. Our current focus is just on making the best possible mobile developer experience which means that the current API is tightly coupled to the Android API. We do have plans for a pure Java API down the line though.
Realm uses a custom C++ core that is different from SQLite, and we published a bit about the architecture here http://realm.io/news/introducing-realm/#fast. Both iOS and Android API's are just wrappers around this core.
Hi, Brian from Realm here.
Surely hard to find much info about the internals yet. We could and should absolutely share more about that in a blog post. And to be honest we have for a long time wanted to do that, but just prioritized to enhance the features and support people building apps. We will get back on that.
I'm not sure I can make it justice in a few words :-) But shortly:
The core has been developed from the ground up in C++ over the last 3 1/2 years. Realm’s efficiency comes from leveraging bit-packing, caching, vectorization, query algorithm innovations and a zero-copy architecture to realize gains in memory usage and speed. Data is stored in a single memory mapped file. It uses copy-on-write MVCC (Multi-Version-Concurrency-Control) allowing very efficient fully ACID serializable transactions.
The core is exceptionally fast, which we can leverage to make easy to use API's in the different languages (currently Java, ObjC, Swift and more to follow) and still maintain a speed and functionality advantage.
22 comments
[ 2.6 ms ] story [ 63.9 ms ] threadIt is an interesting metric for us, given that sqlite has for a long time (rightfully) claimed to be the most widely deployed datebase in world, which is also primarily based on their usage on mobile devices.
Realm Inc. already generates revenue by selling additional enterprise products & services around the technology.
No inheritance. No nested transactions. No RxJava support (due to threading issues with Realm). Many annoying random errors (for example, get a row then close the DB connection -> You can't use those results after. Although I believe that this is by design because Realm doesn't cache any data - it queries every time it's requested AFAIK).
It's definitely on the way to being an awesome asset, but it's not there yet!
We seriously love to get the feedback so we can prioritize the additional features our users desire the most.
That said, we are very encouraged to see that the current features satisfy a lot of "non-toy" apps as well and that many thousands developers are building new apps every week.
You can see some of them mentioned here: http://realm.io/users/, and at the end of that page is also some unedited interviews with developers.
/Brian from Realm
It basically provided everything i needed out of the box, and i have dictionaries with 250,000 - 400,000 words that returns BEGINSWITH queries sorted by most used words faster than anyone would be able to type. (below 20ms on an iPhone 5)
I had actually implemented everything in CoreData (sqlite) at first, but when i fell over Realm i gave myself a couple of hours to test it out, and haven't looked back since. It has a really small API surface, so if you're considering to use it I would definitely recommend you to try it out, it wouldn't take a long time to find out if what you need is available.
1) http://typenineapp.com
---
I've been working on a comic reader app for iOS for about 3 years (http://icomics.co). Up until last year, I was using Core Data to persist both metadata information for each comic, as well as per-page caching information to disk.
Unfortunately, Core Data hit a breaking point with me (I encountered a rather catastrophic data corruption issue when trying to get it to perform automatic schema migrations :( ) and, initially as a feasibility test, I decided to try migrating the whole solution over to using Realm. If it wasn't up to the task, my backup plan was going to have been moving to raw SQLite (and all the boilerplate code that that would have required).
Suffice it to say, I was more than impressed with Realm. Since it more or less followed the same objects model as Core Data, porting my apps entire data implementation over to it took less than a single evening of work. The API was ridiculously easy to learn, and I found it much easier to pass data between threads than what I was needing to do to achieve the same result in Core Data. It was also VERY satisfying deleting giant swaths of Core Data code. ;)
I was so impressed with the whole process that after that, I held a talk on it at a local iOS meetup in my city. Afterwards, I uploaded the talk as a video to YouTube (https://www.youtube.com/watch?v=cGptaE2_WEQ) and it was thanks to this video that Realm found me, and how I joined the company. :)
Realm's been in production use in my app for 5 months now, and I can safely say it's performed above and beyond my expectations. For iOS projects, I definitely recommend it. :)
The core has been developed from the ground up in C++ over the last 3 1/2 years. Realm’s efficiency comes from leveraging bit-packing, caching, vectorization, query algorithm innovations and a zero-copy architecture to realize gains in memory usage and speed. Data is stored in a single memory mapped file. It uses copy-on-write MVCC (Multi-Version-Concurrency-Control) allowing very efficient fully ACID serializable transactions.
The core is exceptionally fast, which we can leverage to make easy to use API's in the different languages (currently Java, ObjC, Swift and more to follow) and still maintain a speed and functionality advantage.