[edit - one additional point which is probably more important than the rest. if you've already done one rewrite and you're thinking of another, your problem is

[edit - one additional point which is probably more important than the rest. if you've already done one rewrite and you're thinking of another, your problem is you probably don't know how to move the ball down the field in a business sense so you're picking up the only hammer you have - technology choice, and repeatedly swinging it. Take a step back, ask yourself if the problem is fear of the unknown, and attack the true problem - how do you get users to USE your product. If truly the answer is "my users don't want me to use Rails", I'd be shocked.] First, I'd say I don't think you have anything to worry about. Second, don't go replacing MySQL because you're worried about scale. I have yet to find a database that really easily scales better. You can trade a whole lot of development time to use something like Cassandra or Riak, (which are both great for particular applications). Then you spend a huge, huge amount of time building queries that were easy in Rails and you actually didn't solve any end-user facing problems. You just made it where only one of your developers actually can create queries and nobody can maintain the code. Third, don't go replacing Rails because you're worried about scale. It's not the fastest thing but it's just not worth losing sleep over. Just add the appropriate technology where you need it - I probably wouldn't build a recommendation engine in Ruby; perhaps that is the only piece that you build using something else. Here's what we often do @ Inaka - web and admin in Rails, business "logic" and stuff that needs to scale (either because we have tons of socket connections or because we have a lot of data to crunch) in Erlang. (Insert Java or Python or whatever you need for the backend piece in place of Erlang.) Then build an internal HTTP API that Rails can talk to. Abstract that in a model class. Have Rails call into it as needed. RecommendationEngine.recommend(...) returns JSON with the magical results for your Rails app to render appropriately. Typically we give our Rails users an "api key" (that they don't know about) that is used to authenticate calls to the backend service, so we don't even have to share user authentication schemes between the systems. Then you can use devise or whatever you want for Rails but don't have to re-implement the same password hashing algorithms - authenticating those users is just a quick lookup in the user table. Sometimes that service API may even be part of a publicly available HTTP API. For instance, imagine the backend piece exposes part of its API to mobile devices. Then, some of the methods may be authenticated and some are open to the world.