What is Dgraph lacking?

I’m not sure if this is a useful suggestion, but I run Firebase’s Firestore in production for a small, nonprofit application. Two well known limitations of Firestore are that it doesn’t support full text search and it doesn’t support relations/joins.

I was just reading Algolia’s docs to see how their search product works and I see it only supports full-text-search. It doesn’t support searching across relationships.

As a side product, it seems possible dgraph could offer an Algolia like SaaS offering that focuses on searching across relationships (and you could throw in the limited full text search capabilities that dgraph already has). Rather than a competitor to Firestore, this dgraph side product would be a compliment to Firestore and other services (I’m focusing on Firestore here because that’s what I’m familiar with, but I expect MongoDB and other products would similarly benefit).

A user could sync documents containing relationships to this new product and then search across those relationships. The user would then receive matched document IDs in the response, which they would use to find the original documents in Firestore (or whatever database they’re using) similar to how Algolia search works.

The primary theoretically difference between this product and dgraph itself is the scale/complexity. There would only be a SaaS offering (presumably built using dgraph the database) and every document uploaded would have all fields fully indexed by default. I imagine you could simplify the security model as well as, perhaps, discard real-time-updates and transactions since Firestore (i.e. the real database) would be providing those features itself and this would just be a serverless search/indexing tool.

It’s possible that this suggestion is basically a suggestion to create dgraph. After all, if Algolia supported relationships it’d basically be a database. But I imagine there’s a lot of features you could skip if you lean into the idea that your product will be a compliment to other products like Firestore. And then over time you could flesh out the features to make the product into a full database.

I say this as someone who tried Dgraph and found it to still be half baked (e.g. the graphql API doesn’t support nested filters but I expected that to have been part of the MVP).

Anyway, this feels like an off-the-wall suggestion but I was just reading the Algolia docs and thinking, “It would be great if there were a product like this for relationships…” Seems like such a product could be built on top of dgraph. Please no “DQL” though.

5 Likes