GrapheneDB

@andreasklinger TL;DR: A few hours to get started, days to get something in production. Golden features: Up to x1000 better performance for connected queries or queries with plenty of joins. Possibility of doing a dynamic number of joins (there are no joins really, but equivalent) and a more natural data modeling. Long version: Neo4j comes with an awesome built-in web UI running on port 7474 by default that will let you run queries and visualize results (also accessible on GrapheneDB instances). This web UI also comes with a self-service online tutorial à la Try-Ruby that will insert some sample data and walk you through some basic Cypher queries (Neo4j's query language). There is also a free online-course offered by Neo Technology (makers of Neo4j) at http://neo4j.com/graphacademy/on.... Alternatively there also in classroom trainings and meetups all around the world. See http://neo4j.com/events/#/events.... These courses are designed so that after completing them you have enough knowledge and confidence to start building your own graph-enabled app or feature. You will also find some data modeling examples and Cypher tutorials in the official docs at http://docs.neo4j.org/chunked/st... and http://docs.neo4j.org/chunked/st... and http://docs.neo4j.org/chunked/st.... Regarding data modeling there are also excellent executable examples for many different domains at http://gist.neo4j.org and you can also post your own to start a discussion. The minimum viable knowledge you need is how to model your domain as a graph and how to do queries. You can be up and running with some basic stuff within a day or two and then add complexity from there. Neo4j's Cypher query language is extremely readable and self-explanatory, kind of "SQL goes ascii art" ;) Example query to retrieve friends-of-friends for Andreas: MATCH (andreas { name: 'Andreas' })-[:knows*2..2]-(friend_of_friend) WHERE NOT (andreas)-[:knows]-(friend_of_friend) RETURN friend_of_friend.name, COUNT(*) ORDER BY COUNT(*) DESC , friend_of_friend.name This will retrieve all friends of friends of Andreas, leaving out those who already friends with him, return a list of their names, based on the number of common friends. And as mentioned above, it will only look up an index once to find the Andreas node. Unlike with other databases, the performance of this query depends basically only on the number of local connections, not the amount of knows relationships in the database.

@xnomagichash Hello Brendan, thanks for providing feedback! I agree that we should communicate pricing and features based on the customer value that they provide. It's possible to estimate how much disk storage is needed for a certain amount of nodes, relationships and properties, but besides storage it's hard to predict the resources that a particular project will require (expected throughput, complexity and type of queries, etc.). Some projects require a lot of memory but little CPU, others the other way around. Requirements for different projects are basically different. We communicate some customer value on the different tiers: priority, basic or no support, uptime expectations, backups, SSL. This, combined with the price seems to be enough for most prospects to identify themselves with a certain category. Examples: * "We need 24x7 priority support and automated backups" => Performance * "We are a self-funded startup in pre-launch phase. We need backups but uptime is not extremely critical for us and we're on a budget" => Standard). Perhaps after finding the right category, we could provide a calculator/estimator that will help users identify the plan that they need as a starting point. We'll definitely work on improving that. Now, on to the last section of your comment: > I get the feeling that if I had enough expertise in Neo4j to anticipate how much RAM I'd need for a particular application then I'd probably be deploying it myself. We're not on the business of telling users how much RAM they need or re-selling machines. The main value that we provide is that you don't have to worry about your database: we take care of backups, monitoring, downtime and provide excellent support backed by experts. To match our service running your own box you'd have to: * tune your machine and database configurations * automate backups * monitor backups, to ensure that you can depend on them * monitor instance * be on call 24x7 if there's an issue * know what to do when shit hits the fan, wether it's something with Neo4j or with Amazon or anything else * have a team of multiple people that know how to do all of this in case you want to go for a drink, be sick or go on vacation. There are definitely companies out there with ops teams that are capable of and willing to do all of this, but then I'd say those companies aren't necessarily looking for Database-as-a-service. If you've gotten the impression that we just host machines then we might need to improve our communication of the value proposition. In this case, making us aware of this would be very valuable feedback for us. Thanks again!