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.
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. :)
More so a model where if I say own a business, want a pool of independent contractors I've vetted to view jobs, and give them an opportunity to pick up and perform a job. Example is something like Handy.com but more niche for a solo business.
I do try sometime google especially for code related work. Duckduckgo is best for the people who are ready to sacrifice more accurate results against privacy.
Now, I am in extreme confusion, whether open-sourcing all code will give me better revenue and recognition or I should continue selling code as I do now.
1). Either "open source code solution" - allowing other members to fix, enhance, optimize the app.
2). OR, "one-time licensing fees with open source code allowing a change in code for own use case -AGPL"
3). "if monthly then - expecting constant updates and innovation on the product on a regular basis" to justify the subscription fees [still self-hosted and not on other parties cloud].
