This weekend we rolled the innagural deploy of our top secret new rails app to production. We are currently using Rails 2.1, SQLite and nginx proxying to Mongrel. Why bother with Apache (ever) and MySQL before you have to? Additionally we’re on a 256MB slice from Slicehost which is already serving an FB app, so I’d really rather not have the overhead of heavy tools for light applications.
I think I’m a fan of SQLite even though I just started using it. As they say on their site:
The basic rule of thumb for when it is appropriate to use SQLite is this: Use SQLite in situations where simplicity of administration, implementation, and maintenance are more important than the countless complex features that enterprise database engines provide. As it turns out, situations where simplicity is the better choice are more common than many people realize. ... SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites).
I’m 99.9% of all websites! And simplicity is important to me, I’m configuring enough already; plus I should probably coding some features or something too. And even if scaling does become an issue, I’d first set up memcached, then analyze and optimize my db tables, then upgrade to a fattier slice, then upgrade to an even fattier slice, then consider a more “enterprisey” database solution: multiple servers and jet-packs for the queries.
Meanwhile, I encountered a “problem” with deploying SQLite to production via Capistrano. This “problem” basicly stemmed from monumental laziness and not reading (or configuring) the default database.yml file. Here’s the thing: on development SQLite works great because you keep updating and committing in your same local directory with your same DB file. In deployment however you usually check out a whole new copy of your app, update some symlinks, and blast off into the night. By default this creates a new SQLite db, and doesn’t include the migrations (they were applied to the old copy). I actually started searching google for the answer to this “problem”, thinking about changing my deploy.rb to update a symlink to the SQLite file… but then it was so much easier to:
production: adapter: sqlite3 database: /absolute/path_to_db/on_server/production.sqlite3 # instead of db/production.sqlite3 timeout: 5000
I’m actually almost embarrased to post this “solution” but maybe some wayward youth like myself will find it and save some trouble.
6 thoughts on “Deploying SQLite to Production w/ Capistrano”
Ah! The solution is so obvious. Thanks.
Ha, obvious indeed. But saved me some time and frustration 🙂
Wow, that was obvious… Thanks for the tip, you saved me a real headache.
Yeah! Love that post. Sometimes things are just sooo dead simple. Thanks 🙂
Thought obvious, yet took time to figure out. Thanks for your post 🙂