For various reasons I've ended up as the SQLite rep w/in Chromium, and I bookmarked that page awhile back to periodically revisit. People often seem to believe that SQLite magically solves tons of problems with their persistence layer, without realizing that many of their assumptions are based on things like having a DBA to take care of things behind the scenes, or having a distinct database server process probably running on pretty beefy hardware.
Also, to be honest, I find that developers often don't really _think_ about what they're doing. SQLite essentially gives you a set of b-trees with syntactic sugar over them, so if you cannot adequately describe how your schema works in terms of raw b-trees, then SQLite isn't going to be able to magically make things awesome behind your back. They also don't think about the evolution of their schema over time. So you see developers copy/paste some other code and make it worse, and then never float things by an expert to see if they are making poor decisions, and three years later someone has to disentangle the horror. Also, heaven defend me from people writing ad-hoc array-based query systems that automatically generate bad SQL. My experience with ORM systems over the years has convinced me that if you spin up an entire dedicated team to work really hard on that problem alone for years, it will still be quite unsatisfying in the end. One developer making a bunch of stuff up and then abandoning it is just a recipe for later pain. There are many places where I think developers would have been better served with a shared nosql-type store (like leveldb) mapping keys to something a decent serialization system (like protocol buffers), and which would have some well-defined and automated procedures for handling things like transaction scheduling and recovery from filesystem corruption and other errors. It wouldn't be as good as SQLite can be, but it wouldn't be as bad as the way many people use SQLite in practice. [To be fair to SQLite, much of my position on this isn't much different than my position on MySQL in a past position. SQL is a challenge for many developers.] -scott On Sun, Jun 14, 2015 at 6:08 AM, Jean Chevalier <jchevalier at gmx.net> wrote: > Somewhat contradictory the Mozilla Foundation being a member of the SQLite > Consortium while their performance wiki prominently features a warning to > developers against using SQLite allegedly for performance reasons. Guard me > from my friends... > > http://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
