Unification. This is the central point of Prolog, it's the mechanism behind matching structured data, while in SQL you would have to implement unification for each individual query, afresh, every time. Unification allows you to "not know" a lot of things about the shape of the data you want to match, whereas with SQL in order to be able to match something you need to know precisely how the data is organized.
Another, unrelated aspect: I/O, system calls, all that stuff that would require from you in SQL database to go outside and implement functions that are loaded into your database in some database-specific way.
Parsing. SQL doesn't offer much in terms of working with strings. Writing as much as a parser for arithmetic expressions with just integers would be a huge undertaking. No sane person would write such a parser unless for some bizarre code-golf challenge. It's trivial to do that in Prolog.
CLFD. This isn't part of standard Prolog, but it comes with most implementations. This allows you easily to write queries about numerical facts (eg. find all factors of a given integer).
To continue in the similar spirit as above: modern Prologs come with a bunch of libraries. You can have an HTTP server in Prolog, or an image processing tool etc. Something that in SQL you'd have to implement outside of it, and load as an external function.
Modules. Prolog code is more amenable to reuse and can be better organized because you can put it in boxes, hide things you want to keep private in those boxes etc. This is while SQL operates entirely in some sort of a global namespace.
The list isn't exhaustive, these are just the things I could think in a short time.
Thank you for the thoughtful comment! Comparing these specific features to using, say, a vanilla general purpose PL such as Python with an ORM and a SQL database, it looks to me like the integration of primitives such as parsing, constraint programming and unification are far stronger. In particular, unification seems to be a material one that you mentioned -- to do this in SQL, you'd have to do contortions around an EAV model which could probably get you to the same area you would with prolog unification, but probably much less efficiently. It does seem like the answer to my question is "ergonomics and efficiency" which is a useful thing to know.
Another, unrelated aspect: I/O, system calls, all that stuff that would require from you in SQL database to go outside and implement functions that are loaded into your database in some database-specific way.
Parsing. SQL doesn't offer much in terms of working with strings. Writing as much as a parser for arithmetic expressions with just integers would be a huge undertaking. No sane person would write such a parser unless for some bizarre code-golf challenge. It's trivial to do that in Prolog.
CLFD. This isn't part of standard Prolog, but it comes with most implementations. This allows you easily to write queries about numerical facts (eg. find all factors of a given integer).
To continue in the similar spirit as above: modern Prologs come with a bunch of libraries. You can have an HTTP server in Prolog, or an image processing tool etc. Something that in SQL you'd have to implement outside of it, and load as an external function.
Modules. Prolog code is more amenable to reuse and can be better organized because you can put it in boxes, hide things you want to keep private in those boxes etc. This is while SQL operates entirely in some sort of a global namespace.
The list isn't exhaustive, these are just the things I could think in a short time.