user_id is not unique, and the join knows

user_id on movie-ratings has 1,100 distinct values across 9,000 rows.

That is 8.2 rows per user on average. Join anything to this table on user_id and every row on the other side is duplicated that many times. If the other side carries a number you then sum, the sum is wrong by roughly that factor.

The reason it is hard to catch is that nothing fails. The query runs, the join is valid, and the result is a plausible-looking number that is 8.2 times too large.

-- the check, before the join
select count(*) as rows, count(distinct user_id) as keys
from movie_ratings;
-- rows 9,000, keys 1,100 → not unique

-- so aggregate to the grain you want first
with per_key as (
  select user_id, sum(release_year) as release_year
  from movie_ratings
  group by 1
)
select * from per_key;

Aggregating before the join is the fix that generalises. The alternatives — joining and then deduplicating, or select distinct over the result — both work occasionally and hide the problem the rest of the time, because they remove duplicate rows rather than duplicate contribution.

The two-line cardinality check above is cheaper than the incident. It belongs in front of every join you did not write yourself. Longer version in Joins that do not fan out and the fan-out pattern.