Grakn – The Database for AI

I don't see how Prolog would suffice as a database.

Prolog indeed seems eminently suitable for this use case.

For example, let us consider the first use case shown on the page:

    graql>>
    match
    $x isa movie;
    $y isa person;
    $z isa movie value "Avatar";
    ($x, $y) isa directorship;
    ($y, $z) isa directorship;
    select $x;

This finds movies directed by the director of Avatar.

Here are a few relations in Prolog that we can use for this example:

    movie('Avatar').
    movie('Titanic').
    movie('Aliens').
    movie('Terminator 2: Judgement Day').

    person('James Cameron').

    directorship(X, Y) :- movie_director(X, Y).
    directorship(X, Y) :- movie_director(Y, X).

    movie_director('Avatar', 'James Cameron').
    movie_director('Titanic', 'James Cameron').
    movie_director('Aliens', 'James Cameron').
    movie_director('Terminator 2: Judgement Day', 'James Cameron').

These are Prolog facts and rules that suffice to illustrate this use case.

In Prolog, we can query this database as follows:

    ?- findall(X, (movie(X),
                   person(Y),
                   movie(Z), Z = 'Avatar',
                   directorship(X, Y),
                   directorship(Y, Z)), Xs).

Note how closely this query corresponds to the initial example!

Prolog answers with:

    Xs = ['Avatar', 'Titanic', 'Aliens', 'Terminator 2: Judgement Day'].

Note that this is in fact more complete than what the example shows:

    results>>
    [
      {"isa": "movie", "value": "Titanic"},
      {"isa": "movie", "value": "Aliens"},
      {"isa": "movie", "value": "Terminator 2: Judgement Day"}
    ]

Interestingly, this misses Avatar!

You could use a subset of Prolog to query Grakn. The language itself is not what motivates the development of Grakn, it's rather a tool that fits the model more naturally.

Grakn developer here. That's interesting, do you have any particular graph database in mind?

Grakn runs fine on a single machine. One of the core architectural points is that the engine should not be too tightly bound to the storage layer. Currently we rely on Cassandra for storage but we are experimenting with other solutions.

The answer to your last question depends on what query you are performing. If the domain you are modelling is represented naturally as a graph, then you can expect much better performance than PostgreSQL (we'll publish some benchmark results soon).