Django: Deploying an application on Heroku with sqlite3 as the database

Question

I want to deploy an application with sqlite3 as the database on Heroku. However, it seems to be that Heroku doesn't support applications with sqlite3 as the database. Is it true? Is there no way to deploy my sqlite3-backed application on Heroku?

PS: I have successfully deployed my application using PythonAnywhere, but would now like to know whether there's any possible way to deploy it using Heroku.

Solution 1

As Heroku's dynos don't have a filesystem that persists across deploys, a file-based database like SQLite3 isn't going to be suitable. It's a great DB for development/quick prototypes, though.

Heroku do have a Postgres offering however that will suit - with a free tier and a basic $9/month tier that are good for hobby/small projects. The biggest benefit over SQLite is that you get backups that you wouldn't get otherwise (plus all the other Postgres features).

There's a guide to updating your settings.py to use Postgres here: https://devcenter.heroku.com/articles/getting-started-with-django#django-settings

Solution 2

Heroku has a detailed article explaining "Why is SQLite a bad fit for running on Heroku" https://devcenter.heroku.com/articles/sqlite3

Comments

[Giles Thomas]

Quick comment from a PythonAnywhere dev -- the filesystem people can use on our site is backed up, so you do get that for SQLite. That said, we'd definitely recommend that any production site should use MySQL (also available on PythonAnywhere, including from free accounts) or Postgres (which is a paid feature on our site).

[Satashree Roy]

@elithrar I'm new to this; can you please explain me what you mean by "don't have a filesystem that persists across deploys" ?

[blubberdiblub]

@SatashreeRoy Heroku's dynos (think small VMs or containers) are very dynamic. They can be spun up and destroyed easily and at any time. Each time a new dyno is spun up, a fresh (i.e. empty) file system compartment is created that goes along with it and it's populated with all "deployed" files of your app and requirements/runtime. In effect that means whenever your app stores data into files, they will be lost when the dyno stops or gets cleaned up. If you run multiple dynos in parallel (i.e. scale up to more than 1), it also means that none of the dynos will see each other's files.