"Real" object databases — "OODBMS" — uses to be a thing, too. They still survive in some niches, like finance and health, though largely as legacy systems. Products like Objectivity, ObjectStore, POET, Caché (which is built on MUMPS), GemStone (Smalltalk) etc. were once big, expensive products that seemed poised to take over from old-hat SQL databases.
Those databases failed not necessarily because the technology was wrong, although they certainly made some choices that didn't help; those databases were often tightly coupled with opaque binary object serialization formats (with no way of looking into a database without going the binary route) that were in turn tightly coupled with the app's class hiearchy. For example, several of these actually post-processed your code (e.g. your Java bytecode) to insert serialization code, so that when you followed a relationship (e.g. "library.books[0].author"), it would automatically query under the hood and return the author as an object. They ended up being clunky to work with as a result; for example, in the beginning, very few of them had a query language, so the only way to query the data was by following relationships through your graph of objects.
Realm looks interesting as a new approach to the object database design, but at the same time seems a bit limited. It doesn't seem to have schemas or any kind of role-based permissions, and seems to make the same mistake of not including a query language (so you can't build a REPL for it, and every language binding needs its own query builder). The transaction semantics also seem to be entirely undefined (is it read-committed?). From what I can tell, it's also "offline first", in the sense that you have a local database that can sync to/from a server, but you're technically always working on an offline copy of the master data; while nice to have for a mobile app, it does limit what you can use it for. I also don't see any support for fine-grained updates. Every write you do seems to overwrite, which I assume means the last write always wins; how do you deal with conflicts, or implement things like counters, maps or arrays that need to be incrementally updated?