SQLite ... quick and dirty SQL server
I was working on a Perl project this weekend. (You know, Perl. "It's like Java, only it lets you deliver on time and under budget." *) I was doing a bunch of awfulness with SQL-over-CSV files, but I really needed a database. I didn't want to go through the hassle of installing one, even though, on Debian, it's just apt-get install postgresql-client postgresql-server. Then I'd have to create database users, muck with security, and then my evening ends up diverted to system admin tasks. I just want a simple SQL engine that's easy to deploy.
You'd think I would have found it sooner. If I didn't dislike PHP so much, I might have found it there. As it was, I only stumbled across it because a module I was using wouldn't work with Postgres's sequences, and as I was wading through the code, I saw it mentioned: SQLite.
So what is it? "SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. ... SQLite is not a client library used to connect to a big database server. SQLite is the server. The SQLite library reads and writes directly to and from the database files on disk."
It's beautiful. It's simple. It's embeddable. There's a Java binding wih JDBC. And it's "two times faster than PostgreSQL and MySQL for many common operations."
It's not for everyone. The security is whatever the OS provides for files. It's not fully SQL92 complete (here's the list of what it doesn't do), even compared to MySQL. The locking is file-based and operates on the whole database.
Oh yeah, it's typeless. Want to shove some text in an int column? Go ahead. It's OK.
For simple apps that need to do a little SQL, but don't need all the bells and whistles, it's great. And for developers running local test cases all over, without wiping out production or semi-production databases, it could be a lifesaver.