Dgraph: 12 Reasons that make it the Best Database of 21st Century
With great pride let me introduce you to the best in class Database, & why you must be using this for every project going forward.
A while back I was dreaming of a project, that I thought had a lot of potential, and started scouring the internet, for the right technology, to make it happen.
I was new to System Design, so I just went blindly through the top of the list for every technology, to make the backend.
Turns out the technology at the top of the list may have been the best in the previous century, but in this century they feel like they could use a revamp.
Not just the tech stack itself, but how we talk to the backend. Everyone needs to get their hands on GraphQL to feel how revolutionary it is compared to what REST has to offer.
That brings us to Dgraph. See:
I would go over each of the features that will prove why:
Dgraph is truly a 21st Century Database!
Versus
See the official comparison by Dgraph: Dgraph compared to other Databases.
I didn’t include a section for Dgraph vs other Graph database because it just wins outright against the biggest contender & Dgraph has a comprehensive comparison available. See: Dgraph vs Neo4j.
1. SQL Databases
SQL Databases are chosen for ACID Properties, and relational nature.
But can’t Graph DBs guarantee the same? What makes it so that only Relation Database are capable of those guarantees?
Dgraph meets all of the criterias a old school Relational Database does:
- Atomicity: Transactions are there in Dgraph. See: Transactions Documentation.
- Consistency: The database must remain consistent, before & after transaction. See: Jepsen Test result on Dgraph.
- Isolation: Multiple transaction occur independently without interference. See: Snapshot Isolation used by Dgraph.
- Durability: The changes of a successful transaction occurs even if system failure occurs. See: Raft Consensus Algorithm used by Dgraph.
Dgraph outperforms Relational Databases in all frontier, and more. For instance it’s Horizontally Scalable, even in free version, which famous RDBMS can’t do out of the box!
2. NoSQL Databases
The need for processing unstructured data, and the need for faster processing led to advent of NoSQL.
Startups are said to prefer NoSQL due to flexible schema, to allow future growth. Well Dgraph also has flexible schema, and lots more to benefit a startup!
NoSQL has lots of advantages, and so does Dgraph. Like:
- Distributed in Nature.
- Highly Scalable.
- Auto Sharded.
- Auto Replicated.
- Integrated Search.
- Flexible Schema Design.
- Reduced Costs.
- Open Source.
- Integrated Caching.
- Faster Writes.
However, Dgraph doesn’t suffer from the cons of NoSQL, Like:
- ACID Transactions in Dgraph is first class.
- Fine grain security is possible with Dgraph.
- Dgraph uses GraphQL for queries and not some obscure language.
- Faster reads.
Features
Following features puts Dgraph at the upper echelon of Databases.
3. Native GraphQL
Just look how swift Dgraph can let someone make a Twitter Clone!
New Databases are cropping up, that introduce a layer on top of their Relational DB to allow GraphQL query, and all they end up doing is bloating up the stack by using Adapters that convert GraphQL to SQL or some other translations that introduce overhead.
Then there are services like Hasura, that generates the GraphQL API for existing database. But it comes nowhere close to how good a Native GraphQL solution gets.
GraphQL and Graph Databases are meant to play along, and having it as first class citizen of the Database makes it so much better. (Think Apple Hardware & Software.)
Using GraphQL means:
- Overfetching & Underfetching are things of the past.
- No N+1 problem.
- Great for mobile devices because of lighter payload.
- Subscriptions, so server can let front end know when something changes. (For example after file is processed, or when message received from a live chat!). See: Apollo GraphQL Subscriptions.
- Self documenting, no need to maintain documentation separately & any app can display the documentation via Introspection of the GraphQL Endpoint. See: GraphQL Playground.
- Ease of handling deprecations, without introducing versioning and fragmenting the backend. See: Deprecation Dgraph.
- It’s scalable, as endpoints don’t have fixed payload, so the same endpoint can be used everywhere.
- Response key aliasing is easy. See: Aliases. (No more sausage case & camel case discrepancies!)
- Client driven development, no more reliance on Backend to make changes.
- Caching is possible. See: Apollo GraphQL Caching.
- GraphQL can even act like an API Gateway between multiple microservices.
Dgraph Query Language: (Previously GraphQL±)
Dgraph Query Language (DQL) is based on the GraphQL specification created by Facebook. GraphQL wasn’t developed for Graph databases, but its graph-like query syntax, schema validation and subgraph-shaped response make it a great language choice.
So Dgraph modified the language to better support graph operations, adding and removing features to get the best fit for graph databases.
Advanced users can use DQL to send queries and mutations to Dgraph endpoints using the Dgraph client libraries.
See: Advanced Queries Documentation and DQL Fundamentals for more.
4. Distributed
A distributed system has multiple components located on different machines that communicate and coordinate actions in order to appear as a single coherent system to the end-user.
That means, instead of having one big machine doing all the work, multiple smaller machines can divide the work among themselves.
Which allows a company like Google to scale to Googol!
Traditional RDBMS can’t do that, you either move to a recently introduced RDBMs that introduced horizontal scaling or use a plugin, like you do with PostgreSQL. That is you would need Hyperscale (Citus)!
So why not go with a Database, that already beats other Databases in all aspects and is Distributed in nature out of the box!
Being distributed allows a system to be:
- Horizontally Scalable.
- Auto balanced across shards.
- Synchronous Replication.
- Fault Tolerant due to Raft Consensus Algorithm.
Dgraph is also Jepsen Tested, so it is guaranteed that the Database meets all challenges of a Distributed System.
5. Blazing Fast
Graph databases are much faster than relational databases for connected data — a strength of the underlying model!
Graph Databases also make modelling and querying much more pleasant, meaning faster development. It’s natural to think and draw in Graph shape than in tabular format.
Hence Graph Databases beat the traditional databases hands down, which puts Graph Databases way ahead of other DBs.
Then comes the Dgraph’s competitors like Neo4j, which can’t even hold candle to Dgraph’s lightning performance!
Dgraph is significantly faster compared to Neo4j, as it’s:
- Written in Golang, so no JVM to warm up.
- Optimized for SSD utilizing Badger DB! (Think of SSD as cheap ram, than costly storage!)
- Concurrent caching enabled by Ristretto. See: Blog post on Ristretto.
For a comprehensive understanding, look at the benchmark done by Dgraph:
6. Geolocation
Geolocation has become an integral part of mobile applications, especially with the advent of smartphones in the last decade, the list of applications which revolves around users location to power application features has grown beyond imagination.
Real-world data is interconnected; they are not sparse; this is more relevant when it comes to location data. The natural representation of railway networks, maps, routes are graphs.
The good news is that Dgraph, the world’s most advanced graph database, comes with functionalities to efficiently store and perform useful queries on graphs containing location data. If you want to run queries like find me the hotels near Golden Gate Bridge, or find me all the tourist location around Golden Gate Park, Dgraph has your back.
Yet databases often lack this basic feature. For example if you use Postgres, you would need Postgis.
7. Truly Relational
Graphs are more relational than the Relational DBs pretend to be.
The primary keys, the foreign keys and all that junk. It’s like manually placing the wire on the mechanical board to patch in a call from one end to the other like in old days, when telephones first came to be.
- Can’t we just let the natural Graph Data Structure handle the relations?
- Can’t industry use the Data Structure that was forced down our throats, in University, instead of a tabular structure?
- Data is multi dimensional, then why do we resort to using two dimensions to store it?
- Graph can easily handle multiple dimensions, right?
Normalizing data is so much old school. Can we please move on, and just use a Data Structure that doesn’t store data repeatedly and yet is able to retrieve data quickly!
So many issues can be avoided, if we just embrace higher dimensions. Instead of living like ants on 2d plane, let us soar through the space with Dgraph.
If Graph Database can handle a complex relational websites like social networks, then it can definitely handle every other kinds of relational data.
8. Easy
It’s the easiest Database there is. No need to learn boring syntaxes, joins, normalizations.
Easy to learn, easy to set up, and most importantly easy to use!
Dgraph is Docker & Kubernetes native, so it plays along great. See: Dgraph Docker Images.
The ease with which you can define GraphQL Schema is mind blowing. You can use Interactive Schema builder or just plain text, and all the CRUD APIs get generated by Dgraph!
- Why even bother writing the backend, if all we need to do is write the schema and the DB Updates itself seamlessly?
- Manually creating CRUD APIs should be the thing of the past. When can we learn that there is a better way?
Dgraph allows us update the schema whenever we desire, and the Graph updates accordingly.
You can use Swagger Editor to generate Server stubs REST APIs, with OpenAPI specification, but that doesn’t even scratch the surface of what Dgraph does.
To top it all, Dgraph even has Slash GraphQL, it’s hosted managed Dgraph service. And if that doesn’t say easy, I don’t know what does!
9. Powerful Search
Search functionality is a must in a Database, having it built in and not having to create a separate Datastore for search functionality is just a blessing.
Dgraph uses indexes to make search efficient.
int, float, geo and date have default indexes, but string has options of what index types to choose. Multiple indexes can be built for the same string valued predicate.
For string the following indexes are available
termfor use withalloftermsandanyofterms. (default)exactfor use with inequality - matching whole string.hashas forexactbut hashes string - useful with long strings.fulltextfor full text search withalloftextandanyoftext.trigramfor use with regular expressions.
Fulltext is the most advanced of the lot:
Full text search is what Google does for web pages. It’s different to term matching because it tries to respect language, grammar and tense. For example, matching search term run with documents containing run, running and ran.
It doesn’t match terms exactly and instead makes use of
- Stemming: Finding a common base word so differences in tense, plural / singular or other inflection are still matched, and
- Stop Words: Removing words such as and, or, it and maybe that occur too often to search over.
10. JWT based Auth
Dgraph GraphQL comes with built-in authorization. It allows you to annotate your schema with rules that determine who can access or mutate the data.
There are two important concepts in auth:
- Authentication: says who you are.
- Authorization: says what you are allowed to do.
Dgraph does it amicably, and plays nicely with Apollo GraphQL.
11. Custom Business Logic
If generated CRUD API falls short of your requirement, i.e. Factory made superbike doesn’t float your boat, then you can add custom business logic using JS Lambda Functions
Dgraph Lambda is a serverless platform for running JavaScript on Dgraph and Slash GraphQL.
See: Building Serverless GraphQL Apps Using Slash GraphQL | Workshop.
12. Encryption & Compression
Dgraph uses Badger DB underneath to separate Encryption & Compression out from the core DB.
Encryption:
Dgraph does Encryption at rest, which refers to the encryption of data that is stored physically in any digital form. It ensures that sensitive data on disks is not readable by any user or application without a valid key that is required for decryption.
Dgraph provides encryption at rest as an enterprise feature. If encryption is enabled, Dgraph uses Advanced Encryption Standard (AES) algorithm to encrypt the data and secure it.
Compression:
Dgraph saves storage space by compressing every block of data using one of the two compression algorithms provided: Zstandard or Snappy.
Compression is enabled by default, no need to pay for the feature, to save money on storage!
Conclusion
Hope I have shed enough light to convince you to opt for Dgraph.
If you are stuck with other Databases, use Live Loader & Bulk Loader to port the data into Dgraph. Else if you are starting from scratch then definitely go for Slash GraphQL, the official managed offering from Dgraph Labs.:
YSK: Most System Design Interview questions can be answered with Dgraph!
The Community behind Dgraph is massive, and so is the company. The database is Open Source, so if you aren’t using it, maybe you can contribute!
Let me know your thoughts down in the comments below.
Share this on:
Twitter | Facebook | Pinterest | LinkedIn | Tumblr | WhatsApp
If you liked this, you might also like:
