Dave Thomas tries to answer a question he gets asked a lot; is Rails ready for prime time?

His answer is, as usual, a pragmatic one that I fully support. His list of when you shouldn't use Rails hits the jackpot:

When shouldn't you use Rails?

• If you need to handle transactions across multiple databases. Rails/Ruby doesn't have two phase commit (yet).
• If you have really strange database schemas. ActiveRecord beats Hibernate when the schemas are fairly well structured. Hibernate wins when you have to map the schema-from-hell before using it inside your application.
• If you're adding small chunks of functionality to an existing, large application. OK, this is contentious. If I was reading this, I'd probably fire up my mail client and complain that this is exactly when you should use Rails. Integrate to the monster using web services, and add new functionality in something more malleable, such as Rails.
  Except... most monstrously large applications I've come across got there over time. They're messy, hard to work with, and tightly coupled. If you wanted to expose parts of them via web services, you'd first have to restructure them to make those parts callable from the outside, and that probably isn't worth the effort (if it's possible at all).
• The developers don't want to. If the rest of the developers don't want to use Rails, then forcing them to help you create a pilot project is a simple recipe for embarrassment. Pull, don't push, when it comes to change.