On a syntax level, parsing, generating, and templating datalog is _much_ simpler than doing the same to SQL. DBT would never exist if every SQL database accepte

On a syntax level, parsing, generating, and templating datalog is _much_ simpler than doing the same to SQL. DBT would never exist if every SQL database accepted datalog queries and SQL injection attacks would be rare to non-existent. The more interesting answer is to think of datalog as making it easy to encode nearly all of your application logic as a bunch of self-referencing, incrementally updated, materialized views. Some examples: # view of Users table for currently logged in user LoggedInUserView(name, email, id) :- Users(id: payload["userId"], name, email), Cookies(name: "login", payload). # view of Users for admin AdminUserView(name, email, id) :- Users(id, name, email), Cookies(name: "login", payload), payload["isAdmin"] = true. # posts a user can see PostsView(title, content, id) :- Posts(title, content, public: true). PostsView(title, content, id) :- Posts(title, content, author: payload["userId"]), Cookies(name: "login", payload). And then you write your UI code to explicitly reference these derived views rather than manually wrapping an API around querying the Posts table and doing the filtering. The examples above can be neatly replicated in Supabase or Postgraphile (the OG of auto-generated GraphQL over Postgres), but you can do a lot more with datalog as a language. The Hellerstein paper mentioned above is a good starting place.