SQLite in development, PostgreSQL in production—why not?

Question

Heroku advises against this because of possible issues. I\'m an SQL noob, can you explain the type of issues that could be encountered by using different databases?

Answer 1

I used sqlite3 in development and postgres in production for a while, but recently switched to postgres everywhere.

Things to note if you use both:

• There are differences between sqlite3 and postgres that will bite you. A common thing I ran into is that postgres is stricter about types in queries (where :string_column => will work fine in sqlite and break in postgres). You definitely want a staging area that uses postgres if your dev is sqlite and it matters if your production app goes down because of a sql error.

• Sqlite is much easier to set up on your local machine, and it's great being able to just delete/move .sqlite files around in your db/ directory.

• taps allows you to mirror your heroku postgres data into your local sqlite db. It gets much slower as the database gets larger, and at a few 10s of tables and 100K+ rows it starts to take 20+ minutes to restore.

• You won't get postgres features like ilike, the new key/value stores, fulltext search

• Because you have to use only widely supported SQL features, it may be easier to migrate your app to mysql

So why did I switch? I wanted some postgres-only features, kept hitting bugs that weren't caught by testing, and needed to be able to mirror my production db faster (pg_restore takes ~1 minute vs 20+ for taps). My advice is to stay with sqlite in dev because of the simplicity, and then switch when/if you need to down the road. Switching from sqlite to postgres for development is as simple as setting up postgres - there's no added complexity from waiting.