>>Sqlite is used at the basis of Firefox, Thunderbird, Nokia, Android... you probably have not looked lately ;-)
>>
>>
>>No, I have...I never disputed Sqlite's position, not once. I really wish people would read carefully. What I called into question is the quality of the product.
>
>Open to many interpretations: If you mean breadth of scope of GUI, wizard helpers, large eco sphere from transformation to analysis services: obviosly no contest as SQLite just aims to be the best embedded DB, even not targeting real multi user access.
>
>If you are talking text based vs. binary fields, implementation detail to ease endian problems - SQLite db files are extremly portable. Remembring the niceties of 6800 vs. X86 as well as Real4, Real6 and Real8 I applaud ;-)
>
>For me it is a solidly working bee doing it's stuff extremly well - can you point me to many reports of data loss using SQLite stemming from internal programming errors ? It is not MEANT to be MU-ACID.
>
>regards
>
>thomas

To me, it depends on the requirements of the app. If it shares backend access with other apps with high traffic then there may be issues:

http://www.sqlite.org/whentouse.html

Situations Where Another RDBMS May Work Better

    *

      Client/Server Applications

      If you have many client programs accessing a common database over a network, you should consider using a client/server database
 engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, 
performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and 
Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same 
database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem 
implementation, there is nothing SQLite can do to prevent it.

      A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from
 many computers over a network filesystem.
    *

      High-volume Websites

      SQLite will normally work fine as the database backend to a website. But if you website is so busy that you are thinking of splitting the 
database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database 
engine instead of SQLite.
    *

      Very large datasets

      With the default page size of 1024 bytes, an SQLite database is limited in size to 2 terabytes (241 bytes). And even if it could handle larger 
databases, SQLite stores the entire database in a single disk file and many filesystems limit the maximum size of files to something less than
 this. So if you are contemplating databases of this magnitude, you would do well to consider using a client/server database engine that 
spreads its content across multiple disk files, and perhaps across multiple volumes.

    *

      High Concurrency

      SQLite uses reader/writer locks on the entire database file. That means if any process is reading from any part of the database, all other 
processes are prevented from writing any other part of the database. Similarly, if any one process is writing to the database, all other 
processes are prevented from reading any other part of the database. For many situations, this is not a problem. Each application does its 
database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require 
more concurrency, and those applications may need to seek a different solution.