This is a general approach to questions about persistence, software architecture and scaling a software service.
When you deal with this, the first thing is to decide is if the product you are working on is going to be User Experience Centric (or not).
The second question, is about if what you are doing is traversing a path of a Good Business Experience (or not).
If the answer to both is yes, then making a fast prototype, for instance on Seaside, makes total sense (at least for the first steps of a Lean Startup
Why it does make sense?
you need business hypothesis validation fast
you need to get short development cycles (you need as less impedance in development as you can get)
you need real people’s feedback to make the design reviews (review/redesign of whatever is needed from the UI to the backend).
you’ll have money sooner to fix scaling problems that will happen later (anticipation of capital value/cost)
The problem with most traditional analysis is that they use to suffer of two weaknesses:
assumes that relational/sql is the only reasonable way to persist you model (and still be able to deal with scaling issues)
assumes that you don’t have tools to minimize concurrency issues
The universe do not converge to relational databases (that have their own scaling demons anyway) specially these days where you are plenty of noSQL options (i.e.: Redis
 check story
 or Riak
But if you want to stay pure object, Gemstone
 sounds like the right tool for the job. If you are using Ruby instead of Smalltalk then use this Ruby-managed Gemstone named Maglev
1. Gemstone is a scalable database of objects
2. GLASS is a Gemstone that includes Seaside which, for instance, would allow you to make one transaction per request making concurrency issues minimal or, at least, intuitively solvable.
Just to clarify, I don’t use Gemstone (because I’ve found another convenient way to store objects in a scalable way) but I’d never find appealing the traditional advice of “burning money” trying to map objects into tables just to make your development slower, less flexible and harder to maintain due to Object-Relational-Impedance-Mismatch
(do not insist, they just don’t fit!) .
As one guy told me once...
“Let the scaling problem come to you. It’s a good problem to have. At the time it reaches you, you'll be more experienced and have more money to deal with it”