No post body was provided.
Ask HN: What graph database you use and why? Any alternatives you had?
1–6 of 6 posts
Re: Ask HN: What graph database you use and why? Any alternatives you had?
#2Loving Dgraph for the amazing GraphQL-like language. I believe their latest version(s) are now fully compliant.
I also used ArangoDB, back then it was a lot more stable for bulk loading than Dgraph but today I believe they're on par — Arango is multi-model which can be at times easier to reason about whilst Dgraph is a more graph-native database.
I never liked Neo4J as — back then — the horizontal scaling was impossible or extremely difficult to achieve.
Re: Ask HN: What graph database you use and why? Any alternatives you had?
#3Loving Dgraph for the amazing GraphQL-like language. I believe their latest version(s) are now fully compliant. I also used ArangoDB, back then it was a lot more stable for bulk loading than Dgraph but today I believe they're on par — Arango is multi-model which can be at times easier to reason about whilst Dgraph is a more graph-native database. I never liked Neo4J as — back then — the horizontal scaling was impossi…
Do you see any performance or disk-space difference between "Dgraph" & "ArangoDB" ?
Re: Ask HN: What graph database you use and why? Any alternatives you had?
#4Loving Dgraph for the amazing GraphQL-like language. I believe their latest version(s) are now fully compliant. I also used ArangoDB, back then it was a lot more stable for bulk loading than Dgraph but today I believe they're on par — Arango is multi-model which can be at times easier to reason about whilst Dgraph is a more graph-native database. I never liked Neo4J as — back then — the horizontal scaling was impossi…
Do you see any performance or disk-space difference between "Dgraph" & "ArangoDB" ?
Both have been pretty efficient with disk space despite our multiple indices. More complex queries did perform a lot better on Dgraph though.
End result, though... We moved everything back to Postgres and prefer to use recursive queries and metadata to query more efficiently.
I love graph database and the dream they sell, but it's just not worth it for a small entity like ours. Takes too much time dealing alphas, nodes, rebalancing shards, and so on.
But otherwise, check these two are they were great if it weren't for fleet management.
Re: Ask HN: What graph database you use and why? Any alternatives you had?
#5Earlier quoted context omitted.
Do you see any performance or disk-space difference between "Dgraph" & "ArangoDB" ?
Both have been pretty efficient with disk space despite our multiple indices. More complex queries did perform a lot better on Dgraph though. End result, though... We moved everything back to Postgres and prefer to use recursive queries and metadata to query more efficiently. I love graph database and the dream they sell, but it's just not worth it for a small entity like ours. Takes too much time dealing alphas, nod…
I have not found any graph database which is suitable for small apps or for startup which won't scale like crazy, so completely agree on moving to PostgreSQL.
But graph database is all about how complex query or relations are between table or schema and how big are your data in your project.
Re: Ask HN: What graph database you use and why? Any alternatives you had?
#6Earlier quoted context omitted.
Both have been pretty efficient with disk space despite our multiple indices. More complex queries did perform a lot better on Dgraph though. End result, though... We moved everything back to Postgres and prefer to use recursive queries and metadata to query more efficiently. I love graph database and the dream they sell, but it's just not worth it for a small entity like ours. Takes too much time dealing alphas, nod…
I have not found any graph database which is suitable for small apps or for startup which won't scale like crazy, so completely agree on moving to PostgreSQL. But graph database is all about how complex query or relations are between table or schema and how big are your data in your project.
Zhenni from Dgraph here. First of all, thank you for mentioning Dgraph in this topic. Second, not sure if you're aware, Dgraph recently released a beta for a hosted solution called Slash GraphQL. It solves the exact problem that you mentioned here. Slash is a fully managed GraphQL backend service and it gives you a /graphql endpoint in a single click. It is tailored for startups and small apps since it eliminates the backend management completely and allows you to focus on building your app and ship faster. What makes it unique is that Slash is powered by Dgraph, where you can enjoy the benefits of the graph backend (intuitive data modeling with only GraphQL schema) and Dgraph's speed and scalability.
Glad to hear that PostgreSQL satisfies your need. If you're looking to build a new project that requires complex query or relations, definitely give Slash a try. :)