Jag är inte säker på att jag skulle hålla med om uppfattningen att många människor inte gillar SPARQL. SPARQL 1.0 hade visserligen några brister, men det åtgärdade ganska bra vad det var designat för, och den nya iterationen, SPARQL 1.1, bygger på att den lägger till många konstruktioner från SQL som folk förväntade sig att se i den ursprungliga specifikationen inklusive underfrågor, aggregat &uppdatera semantik. Jag tror att det faktum att det är standard och att du kan förvänta dig att se samma analys och semantik i varje trippelbutik, i motsats till dialekter av SQL, är en trevlig funktion.
Jag skulle också hävda att alla trippellager är grafdatabaser; du kan sätta egenskaper på specifika kanter i RDF, om än inte så snyggt som du kan med Neo4j. Men triple stores har fördelen av ett riktigt frågespråk, en w3c-standarddatarepresentation som gör det trivialt att ta din data till en annan triplestore, och för ett antal triple stores, möjligheten att utföra resonemang baserat på OWL.
Jag vet ingenting om skalbarheten för de flesta graf-db, men generellt sett skalas de kommersiella RDF-databaserna ganska bra. Alla kan skalas till miljarder trippel, vilket hanterar många användningsfall. Även om hur de hanterar skalning skiljer sig mycket från leverantör till leverantör när det gäller att skala upp eller ut, klustring, etc. Du kommer också att se ganska olika minnes- och hårdvarukrav för att matcha implementeringarna för var och en. För mig har jag tenderat att bara gå och ta en EC2-instans, vanligtvis en 2XL eller 4XL, montera en EBS som är tillräckligt stor för att hålla data, och jag är ganska väl inställd.
Dessutom integrerar vissa trippelbutiker med Lucene eller liknande teknologier för att tillhandahålla inverterade index över data, och många börjar nu inkludera geo-spatiala och tidsmässiga index. Det här är mycket användbara funktioner som jag inte är säker på om de är tillgängliga i något som Neo4j.
Med det sagt kommer de inte att skala lika bra som en relationsdatabaser, de är bara inte lika mogna. Men du kommer inte heller att bli skruvad när du har "riktiga" mängder data heller. Naturligtvis är en av fördelarna med triples stores resonemang, vilket att prestera i skala är knepigt, men det är mycket av anledningen till att de olika OWL-profilerna skapades. Men du kan måla in dig själv i ett hörn om du inte tänker framåt.
Jag tror att grafdatabaser, närmare bestämt triple stores, kan vara en ganska bra matchning för många applikationer som byggs, men jag tror inte att det betyder att allt ska göras med dem. Som allt annat är de verktyg med sina goda och dåliga punkter, så du måste göra rätt val baserat på din applikation. Men de förtjänar nog alltid åtminstone en övervägande nu för tiden.