Should the types of databases for development, testing, and production all be the same?
Is it okay to have, for example, sqlite3 for development and testing, and mysql2 for production? Is that doable/common/not too hard to configure?
This just bit me on some hand-coded SQL, migrating from SQLite to MySQL and I didn't get the same results from a query. If you're never touching hand-written SQL or conditions parameters, then you should be fine with mix-and-match. But to be absolutely certain, then you can't beat using the same database in all three environments.
Walter
Hi, I think you can use different databases without any problem, just set it in the database.yaml file. I think this is the only settings you need, but it's wise to check the application.rb file, if any other smart settings are available.
For hardcoding SQL use this tutorial:
and check the API first! This way you won't have any problem.
cheers, Zoltán
Is it okay to have, for example, sqlite3 for development and testing, and mysql2 for production? Is that doable/common/not too hard to configure?
It's perfectly doable, and perfectly okay, and apparently quite common; just complete the appropriate sections of the database.yml file for each of your environments.
Should the types of databases for development, testing, and production all be the same?
"Should"? No... *don't* do it! Even though it is undoubtedly possible,
and lots of people do 
You will be making a total nightmare for yourself when code that
"works" in development "doesn't pass tests", or worse, code that
"passes tests" doesn't "run in production". There are too many
differences across dbs; reserved words, db contraints (like index name
sizes), and general SQL implementation [1]. Make your development
environment as close as possible to your production, and ideally have
your test environment be *identical* to production.
HTH
[1] Only a couple of weeks ago, there was a thread about a migration
that wouldn't run for someone, which ended up being that SQLite
wouldn't add not-null columns to an existing table without a default
value.... MySQL will 
Is it okay to have, for example, sqlite3 for development and testing, and mysql2 for production? Is that doable/common/not too hard to configure?
It's perfectly doable, and perfectly okay, and apparently quite common; just complete the appropriate sections of the database.yml file for each of your environments.
I am a bit confused Michael, see below. Here you are saying it is ok to have different db types.
Should the types of databases for development, testing, and production all be the same?
"Should"? No... *don't* do it! Even though it is undoubtedly possible, and lots of people do
Now you are saying that that they must _not_ be the same. Methinks you mistyped?
You will be making a total nightmare for yourself when code that "works" in development "doesn't pass tests", or worse, code that "passes tests" doesn't "run in production". There are too many differences across dbs; reserved words, db contraints (like index name sizes), and general SQL implementation [1]. Make your development environment as close as possible to your production, and ideally have your test environment be *identical* to production.
Here you say they should be the same I think (which I agree with generally), yet right at the start you said it was ok for them to be different.
Colin
Sorry for any confusion. I was answering the two different questions the OP seemed to ask: 1) *can* you set up different DBs for dev/test/production? Yes you can, and it's very easy. 2) *should* you do it? No - in most cases.
The framework makes it easy to do, and sometimes you might have to
operate with different DB configurations (you might be developing for
a commercial DB you don't have installed locally to your dev
environment...), but given the choice, I would avoid it if at all
possible, and try to ensure my environments are all as similar as
possible.
You might choose to have a different test environment to take
advantage of running tests memory for fast performance - but you would
have to beware of failures of the testing environment (due to db
differences) which weren't necessarily problems with your application
- but if someone is running tests in RAM, they're probably more than
aware of this
Sorry for any confusion. I was answering the two different questions the OP seemed to ask: 1) *can* you set up different DBs for dev/test/production? Yes you can, and it's very easy. 2) *should* you do it? No - in most cases.
I think, when you say "should you do it?" you mean "should you make your databases different?" which is the confusion, because you clearly explain that it's better TO MAKE THE DATABASES AS SIMILAR AS POSSIBLE (right?). So actually, my question, which was "Should the types of databases for development, testing, and production *all be the same*?" should get the answer, "Yes, the databases should be the same," correct?
Bottom line: Although many Rails developers use different types of databases for the three environments, it is best to use the same type of database - e.g. MySql2 - for all three environments.
Sound good?
Yes.
Sorry again - of course, all the environments use different databases
(even if they're all MySQL), but if you use MySQL for dev, SQLite for
test, and MSSQL for production, your life will be more complicated
than had you used MSSQL for all (as that's what the production DB is,
for better or worse)