SQLite CVSTrac

*** 155,160 ****
--- 155,165 ----
  in situations where the same database will be accessed simultaneously
  from many computers over a network filesystem.
  
+ =====
+ Note: 
+ =====
+ client/server usually means that there are multiple client processes and at least one server process. If there is no server process, it is not truly a "client/server" setting. Usually, the server process will access the database at the behest of all clients. In such circumstances, there is no reason for clients to access SQLite (directly) over a network filesystem. Therefore, you can perfectly well use SQLite for client/server applications.
+ =====
  *: *High-volume Websites*
  
  _: SQLite will normally work fine as the database backend to a website.
***************
*** 162,169 ****
  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*
  
  _: When you start a transaction in SQLite (which happens automatically
  before any write operation that is not within an explicit BEGIN...COMMIT)
--- 167,181 ----
  database component off onto a separate machine, then you should 
  definitely consider using an enterprise-class client/server database
  engine instead of SQLite.
+ =====
+ Note: 
+ =====
+ First, what is "high-volume"?
  
! Second, scaling is always problematic, regardless of what technology you use. 
! 
! The first problems in scaling that you will hit, are usually not related to the backend technology, but to the application design itself. For example, if you're sending back a list with all customers to the web browser, it may work well for 50 customers. In a situation where you have 10,000 customers, you will need to introduce at least some kind of <page 1 2 ...> and/or <previous/next> logic and limit the query to (e.g.) 50 customers at a time. Sending too much data for a request and consuming too many server resources in doing so, is a very typical scaling problem; and it is totally unrelated to the backend technology. Conclusion: before you will hit the SQLite limitations, you will hit a string of design issues that limit the scaleability of your application well below the SQLite limits.
! =====
  
  _: When you start a transaction in SQLite (which happens automatically
  before any write operation that is not within an explicit BEGIN...COMMIT)
***************
*** 174,179 ****
--- 186,196 ----
  multi-gigabyte range, the size of the bitmap can get quite large.  If
  you need to store and modify more than a few dozen GB of data, you should
  consider using a different database engine.
+ =====
+ Note: 
+ =====
+ Just as if Oracle, SQL server or any other rdbms don't consume huge amounts in memory when managing large databases ...
+ =====
  
  *: *High Concurrency*

sqlite - When To Use Sqlite