SQLite scalability could be an issue over the lifetime of a web application because of size limits.
>From the SQLite web site at http://www.sqlite.org/whentouse.html: 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. My longest running service bureau app contains about 4 meg/user after 30 months on the air. Assume 100 users (for the sake of argument) and in 3-4 years I'm concerned and looking for a migration path to Postgres. WRT to traffic, SQLite should be adequate. Here is more from their site. SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic. 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. On Mar 21, 4:06 pm, Vasile Ermicioi <[email protected]> wrote: > > It is not recommended. All updates will lock the entire database, since it > > is designed for one user. Also, it does not scale. > > enable wal (http://www.sqlite.org/draft/wal.html) and it will not lock > > Also, it does not scale > > do you have any numbers? at which point it doesn't scale?
