SQLite vs. MySQL/etc...

Justin Reagor — Fri, 11 May 2007 08:41:00 -0400

After reading about the wonderful release of mother Joyent’s Slingshot the other day, I noticed that in the docs it said Slingshot uses SQLite on desktop clients. I thought that this was pertaining to personal preference, support the underdog kinda thing. That was wrong, SQLite is easier on memory because it uses file-io instead of in-memory db access…

“For low load websites, SQLite has worked great in our projects. If you’re doing an application in C, its API is simply unbeatable. Perhaps its most distinguishing feature is that it pretty much ignores types. This is, in fact, a “feature”, and I have found that it gives it flexibility that is lacking in other situations(although, you have to put your dates in very specific formats to get the sort order to come out right…).”

“For web development purposes, if you’re doing a really high load website, you’re going to want to use a non-file based database(personally, I prefer PostgreSQL, but sub MySQL, SQL Server, whatever…)”

“I also can’t express just how great it is for desktop apps though. Its great for 95% of the situations you would need to save data in an application in a “file format” of some variety. It make debugging great(fire up the console on the file your app is writing too and watch inserts as they happen). No configuration at all. No mucking about with binary file formats. No XML parsing.”

(external quote)

I have heard many Rails users glorify the use of SQLite as a testing db… choose wisely! For me, I think I’ll stick to what my apps will probably be using as there primary production db, MySQL. :)

has_many :thoughts: Tag database

SQLite vs. MySQL/etc...