The first session, A CouchDB, Neo4j, Redis, and Node.JS Circus, was by Eric Redmond, one of the authors of the very well worth reading Seven Databases in Seven Weeks.

Eric makes the case for selecting a mash-up of databases: CouchDb because it's a great document store. Neo4j because it's fantastic for managing relationships. Redis is great as both a front-end cache, and as a mechanism to transform data - this last point is a subtle point one, I guess you should have been at NodePDX for the details.

It's nice to see people using node for scripting (personally my main use-case). You can find them in the github repository.

If you have a script that has behaviour if you execute it, that you don't want to invoke if it's required for it's exports, then you may find this idiom of interest:
populateBands() if (!module.parent)

Another node tip: If you're writing a script to populate your RESTful database, Node can very easily overwhelm it with http requests. His code has examples of throttling connections to neo4j.

Eric chose CouchDb over MongoDb for the long polling for changes.

One of things that makes neo4j compelling for Eric is the up-and-coming Cypher query language.

All the document data could have been stored in Neo4j instead of CouchDb, but in a graph database it becomes hard to "see" the data - where does this conceptual document end and the other begin. It becomes hard to get the view of the data that you might want in neo4j (if you were expecting a document database).

In a way, Eric's session wasn't really all that much about node. I'm enjoying the book that this example came from, and I think the topic is important, so I'm not complaining.