Per my understanding, the Rete algorithm and relational database engines essentially solve the same problem: answering to a certain query about a (large) set of relational facts. To me, the Rete algorithm is just more special-purpose along with a fancy caching procedure; I fail to see why it is superior to any of the existing state-of-the-art database solutions such as SQL. In terms of flexibility, SQL is certainly superior. In terms of performance, it is not apparent that Rete yields better average performance.
As you say, relational databases are designed for, essentially, answering queries. Rete, I would rather say, is designed for the specific task of materialized view maintenance (i.e., keeping updated the results of a query, once new changes to the data are applied). Of course, you can answer queries by building a materialized view of them, and this is why SQL query answering and Rete relates to each other.
With regards to efficiency, Rete has been critiziced for wasting too much time mantaining its internal data-structures. This motivated the apparison of other algorithms such as Treat.
In any case, it is worth to hightlight that Rete only deals with relational algebra queries, whereas SQL includes non relational-algebra expressions (e.g.: aggregation functions).