4 ms·
Hi, I wrote that tagline so maybe I can explain the rationale. We initially called ourselves “a database that runs directly inside phones, tablets & wearables”
by timanglade 12y ago
Hi, I wrote that tagline so maybe I can explain the rationale. We initially called ourselves “a database that runs directly inside phones, tablets & wearables” but received some ridicule for that as it sounded like we didn’t expect our readers/users to know what a mobile/embedded database was. We iterated a few times until we found this description, where we explain that we replace both low-level DBs like SQLite and high-level abstractions like ORMs or Core Data (because we have our own object-interface built in), while highlighting the two solutions we replace most often on Android & iOS respectively. I agree it’s still somewhat confusing and your analysis is spot on. We’ll try to iterate on this tagline a bit more!
- pdpi 12y agoSo you actually _do_ provide your own db then? I'd love to know a bit more about this. What drove the decision to roll your own? Seeing as how SQLite is pretty mature and widely deployed, my first instinct if I wanted to tackle this problem would just have been to write the best damn ORM I could on top of SQLite.
- timanglade 12y agoYes we do have our own db. We love SQLite to death but we just saw an opportunity to start fresh, with a modern design that leverages bitpacking, caching & vectorization, and would yield more API & performance benefits than the ceiling most ORMs seems to have hit on iOS & Android. I personally believe that new databases should always be created as a last resort, but in this case I think the amount of apps being built and the problems people we talked to routinely ran into while using SQLite and its ORMs justified this drastic decision.