Hacker News Reader

Comment by Moto7451 | Hacker News Reader

Same reason why one might use SQLite over MySQL. Ease of configuration, no need to have a full blown DB server, lighter weight which makes it great for things like Raspberry Pi type hardware. For hackathons I've found it simpler to just use SQLite so I don't have to deal with MySQL configuration headaches that come up when IP addresses inevitably change.

Outside of NodeJS, I can see this being pretty handy for iOS development. I'm not a huge fan of taking JSON from an API, converting it into an NSDictionary, and then placing it into Core Data and RESTKit doesn't always fit my needs. I think this might work well for local persistence of API data for an offline mode.

View on HN

Are there issues with concurrency though when used in a web application?

Yeah. But if you're not publishing it to the entire world, you probably won't run into them. And there are many other applications where databases are useful, that aren't network servers of any kind.

So is it possible to use this as a database in a web app? What sort of problems would come up with concurrency?

Since the storage engine is a modified version of Tokyo Cabinet, I am assuming that you can have simultaneous readers, but a writer will lock everyone else out. From the Tokyo Cabinet specs [0]:

'Tokyo Cabinet provides two modes to connect to a database: "reader" and "writer". A reader can perform retrieving but neither storing nor deleting. A writer can perform all access methods. Exclusion control between processes is performed when connecting to a database by file locking. While a writer is connected to a database, neither readers nor writers can be connected. While a reader is connected to a database, other readers can be connect, but writers can not. According to this mechanism, data consistency is guaranteed with simultaneous connections in multitasking environment.'

[0] - http://fallabs.com/tokyocabinet/spex-en.html

I'd switch to a full DB server for a production Web App. If you're using an ORM it should be pretty trivial (the one time I've done it, Perl's DBIx::Class made it as easy as changing the connection info hash). I'm not sure how many people hand code their SQL at hackathons but I am not one of them ;).

I use SQLite in small and medium-traffic web apps (the largest one getting about 80000 hits daily) all the time with no concurrency issues whatsoever. My rule of thumb is that if you don't expect your app to require more than one server, sqlite will work just as fine as postgres or mysql.

Interesting! For pragmatic reasons, or stress testing SQLite?

For convenience mainly.. It saves me from having to install a "serious" RDBMS, import data, etc. With SQLite, deployment is simply copying the db file to the server.

Use coroutine based servers, everytime there's guranteed one thread accessing the db.

Reply on news.ycombinator.com