It depends on what you mean by "almost perfectly aligned to the domain of relational databases" but by my standards I can't think of a single production database where that's true, in large part because it's not true for SQL itself.

- Tables are not relations. Tables are multisets, allowing duplicate rows, whereas relations always have a de facto primary key. SQL is fundamentally a table language, not a relational language.

- NULL values are not allowed in relations, but they are in SQL. In particular, there's nothing relational about an outer join.

In both cases they are basically unscientific kludges imposed by the demands of real databases in real problems. "NULL" points to the absence of a coherent answer to a symbolic rule, requiring ad hoc domain-specific handling. So this isn't a pedantic point: most people wouldn't want to use a database that didn't allow duplicate rows (the SQL standard committee mentioned a cash register receipt with multiple entries that don't need to be distinguished, just counted). Nullable operations are obviously practical even if they're obviously messy. Sometimes you just want the vague structure of a table, a theory that's entire structural and has no semantics whatsoever. But doing so severely complicates the nice symbolic theory of relational algebra.

That's the point I'm getting at: there isn't really a "domain" limitation for relational algebra, it's more that there's a fundamental tradeoff between "formal symbolic completeness" and "practical ability to deal with real problems." Eventually when you're dealing with real problems, practicality demands kludges.