4 ms·
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 keep
by nfm 15y ago
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 http://www.sqlite.org/lockingv3.html
- petercooper 15y agoSQLite isn't (typically) slow. It's incredibly performant and used in all sorts of speed critical systems - http://www.sqlite.org/famous.html 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 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.
- nfm 15y agoThanks for the info - I was always under the impression SQLite was hella slow. You learn something new every day!
- tzs 15y agoI'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.