SQLite vs. Postgres, at a glance

There’s a general belief that SQLite is a “slow” database and Postgres is “fast,” and many software packages (including FOSS) insist that SQLite is only suitable for testing and doesn’t scale. However, this doesn’t make much sense when you think about it; SQLite is an in-process database so there’s no communications overhead between the service and the database, and because it’s only designed to be accessed from a single process it can make use of optimistic locking to speed up transactions.

Since I was installing postgres for another purpose on my webserver, I decided to quickly see if Publ performs better on Postgres vs SQLite. To test the performance I compared the timing for my website on both doing a full site reindex, and rendering the Atom feed several times (using the debug Flask server and caching disabled).

This site now self-hosted

I’d been running this website on Heroku’s free tier for a while, but it’s been getting enough traffic that it was getting close to my free runtime limit. So, I’ve moved this over to my own personal server.

However, the site repository is still configured to work with Heroku (as well as being self-hosted), and you can still access the Heroku instance at publ.herokuapp.com to see it in action. They should, for the most part, mirror one another.

Anyway, there will probably be some kinks to iron out in the meantime. But on the plus side, it means this site will finally be accessible via https!