> chiming in... Emil, first of all thanks for moving forward the entire
> graph database world, I've always been fascinated by graphs in general and
> since a few years now thanks to you guys and all the other players in this
> corner we can actually use proper products to build amazing things with.

> I can understand the question the OP asked and I guess may folks including
> myself, at one point or another, have thought about it that way... what if
> your dataset grows? How would I be able to still enjoy all the benefits of
> a graph database and maybe store crazy amounts of data, so much data that
> in fact it's to much for a single machine. My thought process led me down
> the same route... maybe use a layered approach in my data tier ie a graph
> database atop some distributed filesystem (eg ceph) and/or MongoDB.

> Example: say I wanted to do facebook (yes, super-ridiculous example
> but...). I would store connections and such lightweight stuff in Neo4j and
> move anything 'heavy' (read big) down to the fat second layer which is
> storing my 1 PiB of images and videos my users upload every day.

> In the end however (and you hear that from everybody on the road long
> enough and/or somehow directly involved with building the next generation
> database) we have to get used to having a variety of different
> databases/filesystems sitting within out data tier, each one used according
> to their particular strength, so that in the end the entire logic tier
> (people 30 and younger please read 'application' ;) gets the best 'deal'
> for anything data related it has to ask/remember for/to.

> Overall I think such 'but when I need to scale to...'
> questions/discussions however, in practice, just become relevant for every
>  10^6 website/app out there anyway. Neo4j certainly can drive anything the
> random project ever requires just fine... like every other database out
> there as well :)