Ludicrous Mode

Ludicrous mode is available in Dgraph v20.03.1 and later.

Ludicrous mode allows a Dgraph database to ingest data at an incredibly fast speed, but with fewer guarantees. In normal mode, Dgraph provides strong consistency. In Ludicrous mode, Dgraph provides eventual consistency, so any mutation that succeeds should be available eventually. This means changes are applied more slowly during periods of peak data ingestion, and might not be immediately reflected in query results.

Because Dgraph with Ludicrous mode enabled is eventually consistent, it is a good fit for any application where maximum performance is more important than strong real-time consistency and transactional guarantees (such as a social media app or game app).

Enabling Ludicrous mode

You can enable Ludicrous mode by setting the --ludicrous superflag’s enabled option on all Dgraph Zero and Dgraph Alpha nodes in a cluster.

What does Ludicrous mode do?

In this mode, Dgraph doesn’t wait for mutations to be applied. When a mutation comes, it proposes the mutation to the cluster and as soon as the proposal reaches the other nodes, it returns the response right away. You don’t need to send a commit request for mutations. It’s equivalent of having CommitNow set automatically for all mutations. All the mutations are then sent to background workers which apply them continuously.

Trade-offs

As mentioned above, Ludicrous mode provides amazing speed at the cost of some guarantees.

It can be used to handle write-heavy operations when there is a time gap between queries and mutations, or when you are fine with potentially reading stale data.

Timestamps in Ludicrous mode

In normal mode, every transaction gets a start timestamp, and upon commit, it gets a commit timestamp. The transactions are flushed when they receive the commit timestamp. In ludicrous mode, we assign a commit timestamp equal to the start timestamp and execute them instantly, which is why you don’t need to send a commit request for mutation. One of the trades of using ludicrous mode is that the timestamps are assigned when they’re ready to be committed, instead of following the arrival’s order.

Concurrency in Ludicrous mode

Ludicrous mode now runs mutations concurrently to increase the speed of data ingestion. This is enabled by default with 2000 total concurrent threads available, but you can adjust the number of concurrent threads available using the --ludicrous superflag’s concurrency option on the Alpha nodes in a cluster.

Can you use Ludicrous mode in a highly-available (HA) cluster?

Yes, Ludicrous mode works with a cluster set up in a highly-available (HA) configuration.

Can Ludicrous mode run in a cluster with multiple data shards?

Yes, Ludicrous mode works in a cluster set up with multiple data shards.