Hacker News Reader

Comment by nfm | Hacker News Reader

Thanks for your thoughts. I'd argue that SQLite isn't appropriate for production because of its slow speed and highly granular concurrency[1].

I'm all for keeping SQLite as the default database for development - it lowers the barrier for entry to Rails.

But for any app that you hope will someday get real traffic, using MySQL or Postgres in production is sensible and easy.

[1] http://www.sqlite.org/lockingv3.html

View on HN

SQLite isn't (typically) slow. It's incredibly performant and used in all sorts of speed critical systems - http://www.sqlite.org/famous.html. That aside, SQLite isn't going to be a key bottleneck in most Rails applications where the less-than-speedy ActiveRecord is involved ;-)

SQLite's own site - http://www.sqlite.org/whentouse.html - notes that it is ideal for "the database engine for low to medium traffic websites (which is to say, 99.9% of all websites)" where they're considering this being under 100k requests per day.

It does depend greatly on what you're doing, but SQLite can vary from being a bit slower to somewhat faster than something like MySQL (many concurrent writes is where it's going to fall to its knees, not a common small web application scenario). It certainly isn't universally "slow." Searching Google for "sqlite is fast" brings up many good citations.

Thanks for the info - I was always under the impression SQLite was hella slow. You learn something new every day!

I'm curious. Which of the examples at your first link are for speed critical systems? They all seemed to be client side stuff that isn't particularly speed critical, and a couple big companies using it in some unknown way.

Reply on news.ycombinator.com