Django: sqlite for dev, mysql for prod? [closed]

Answer 1

I second all previous answers, adding some explicit reasons:

• MySQL issues Warning exception when you try to store string longer that field width - you won't get them in SQLite, so not only you're string will be different between dev and production, but also program behaviour
• bugs in both backends are different - I remember that once I tried SQLite for dev and MySQL for production, but it turned out that I discovered a bug in MySQL backend which was not present in SQLite one. So I filed a ticket for it and switched to MySQL for testing :-)

And you can even try to compete with SQLite in terms of speed, take a look at my answer for other question:

Increase speed for MySQL table creation in Django?

Answer 2

Why would you want to do that?

• SQLite has no stored procedure support yet.
• SQLite is typeless. You can end up with a lot of typecast problems when running MySQL.
• Also SQLite doesn't support RIGHT join yet.

Answer 3

In short, no; unless you want to unnecessarily double development time.

Answer 4

Just made this major mistake starting off with sqlite and when i try to deploy on production server with mysql, things didn't work as smooth as i expected. I tried dumpdata/loaddata with various switches but somehow keep getting errors thrown one after another. Do yourself a big favor and use the same db for both production and development.

Answer 5

I'd highly recommend using the same database backend in production as in development, and all stages in between. Django will abstract the database stuff, but having different environments will leave you open to horrible internationalisation, configuration issues, and nasty tiny inconsistencies that won't even show up until you push it live.

Personally, I'd stick to mysql, but I never got on with postgres :)

Answer 6

Use the same database in all environments.

As much as the ORM tries to abstract the differences between databases, there will always be certain features that behave differently based on the database. Database portability is a complete myth.

Plus, it seems pretty insane to test and develop against code paths that you will never use in production, doesn't it?