[topicseed]

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.

[provlem]

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.

[_zwp_]

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. :)