I picked SQLite for its minuscule (by today's standards) footprint, simplicity, and ease of deployment.
Why do I get the feeling I've bought into a product like any model in the American car market. With each passing interation the vehicle gets bigger, fatter, and less efficient. This continues until the model bears absolutely no resemblance to the original. But, it does have electric fold down rear seats to the advantage of the totally clueless.
I don't think version 3 has compromised the core premise offered by SQLite, but I agree with your analogy as something to watch for in the future. For instance: the new locking scheme in version 3 is irrelevant to me, since SQLite is embedded in my application and I run it as a single thread. However, I can see that attempts to prevent locking when accessing the db file by multiple threads are something that benefit the core product feature set and are real issues when you write multithreaded code.
On the other hand, when (if) changes are made in order to make multiple programs access a shared db file then I believe we begin to risk code bloat, as in these scenarios one should clearly use a client/server database scheme and there are several good ones already available and proven. There is no need to bloat SQLite to cover this usage scenarior imo.
But of course the code is highly modular. I like the fact that you can ommit some features when compiling by editing sqlite.h (ommit_authorization, etc.) This is a very good design decision, as it allows developers to continue embedding without some of the optional features AND makes it possible to add these features in a very simple way, without a formal plugin mechanism or something like that. So if anything I would request that some of the optional features were always implemented as modules that could be selected at compile time (when possible of course), and everyone would be happy.
Regards, Mauricio
