OK, thanks, my mistake. Not coupled. But still, there is a strong presumption that your app will use a database and wants a database.yml.

The few times I've wanted to just start a Rails app with simple Erb, with models representing data concepts (but not necessarily SQL anything), and evolve out to using a database (if and when needed), have been frustrating.

It's something that has been easy to do in some other frameworks so I tend to see Rails as almost DB-required, if not in fact coupled.

Yeah you can think of rails as requiring a database. You can pretty easily substitute whatever you want at the database level (sqlite3, mysql, postgresql, mongodb, even redis!), but it's the convention that you'll need to store and retrieve data in your webapp. If you don't need to do this (edge case for most of us), then try a different framework like sinatra that isn't accompanied by all the database bloat.

If you're planning on using a DB eventually but don't want to deal with migrations etc. for now, then start with a NoSQL DB like MongoDB (you don't even need to describe your fields, it can be completely dynamic). You can always sub in an RDBMS later on if your design calls for it.

As of rails 3 (was sort of true in 2 as well) you really don't need a database. I've written two rails 3 apps recently that have no database, they're effectively a thin graphical client for a couple of JSON APIs.

Works well, just don't require ActiveRecord and hey presto, your app doesn't have a database (or db rake tasks, etc).

It would never occur to me to write something non data-driven using Rails... because to me Rails is rapid development platform for data-driven webapps.

Interesting that people do though. Any particular reason? What features of Rails did you still use? Seems like an odd use case.