Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using SQLite as production database, bad idea but

We are currently using postgresql for our production database in rails, great database, but I am building the new version of our application around SQLite. Indeed, we don't use advanced functions of postgres like full text search or PL/SQL. Considering SQLite, I love the idea to move the database playing with just one file, its simple integration in a server and in Rails, and the performance seems really good -> Benchmark

Our application's traffic is relatively high, we got something like 1 200 000 views/day. So, we make a lot of read from the database, but we make a few writes.

What do you think of that ? Feedback from anyone using or trying (like us) to use SQLite like a production database ?

like image 633
Hartator Avatar asked May 23 '11 12:05

Hartator


People also ask

Why SQLite is not good for production?

Long answer: It is said you can't use SQLite in production because it doesn't support concurrency (no more than one user can be writing to the database at the same time) and it can't scale.

What are the disadvantages of SQLite?

SQLite Disadvantages SQLite is used to handle low to medium traffic HTTP requests. Database size is restricted to 2GB in most cases.

When should you not use SQLite?

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network. SQLite will normally work fine as the database backend to a website.

Do people still use SQLite?

SQLite is used by literally millions of applications with literally billions and billions of deployments. SQLite is the most widely deployed database engine in the world today.


3 Answers

If you do lots of reads and few writes then combine SQLite it with some sort of in-memory cache mechanism (memcache or redis are really good for this). This would help to minimize the number of accesses (reads) to the database. This approach helps on any many-reads-few-writes environment and it helps to not hit SQLite deficiencies - in your specific case.

like image 54
Manuel Salvadores Avatar answered Oct 06 '22 07:10

Manuel Salvadores


SQLite is designed for embedded systems. It will work fine with a single user, but doesn't handle concurrent requests very well. 1.2M views per days probably means you'll get plenty of the latter.

like image 30
Denis de Bernardy Avatar answered Oct 06 '22 05:10

Denis de Bernardy


For doing only reads I think in theory it can be faster than an out-of-process database server because you do not have to serialize data to memory or network streams, its all accessed in-process. In practice its possible an RDBMS could be faster; for example MySQL has pretty good query caching features and for certain queries that could be an improvement because all your rails process would use this same cache. With sqllite they would not share a cache.

like image 37
Jeremy Avatar answered Oct 06 '22 06:10

Jeremy