Sooner or later you'll write the same buggy code twice: a SELECT to check if a row exists, then an INSERT or UPDATE based on the result. Between those two statements, another connection can do its own check and you get a duplicate-key error — or worse, a duplicate row.
Postgres' answer is INSERT … ON CONFLICT, often called upsert. One statement, atomic, race-free.
The seed has a page_views table with UNIQUE (page, user_email) and a tags table with UNIQUE name. Both are realistic shapes for upsert.
The problem upsert solves
"Record a page view: insert a new row at views = 1, or bump the counter if (page, user_email) already exists."
The naive way is a check-then-write:
SELECT views FROM page_views WHERE page = '/home' AND user_email = 'ada@example.com';
-- If found: UPDATE. If not: INSERT.
Two round trips, and any concurrent writer can slip between them. INSERT … ON CONFLICT collapses both branches into one atomic statement.
ON CONFLICT (...) DO UPDATE
The shape:
INSERT INTO <table> (cols...) VALUES (...)
ON CONFLICT (<conflict_target>) DO UPDATE
SET col = <expr>;
The conflict_target is a column or set of columns covered by a UNIQUE constraint or primary key — Postgres needs an index to detect the conflict against. Here it's the (page, user_email) unique constraint.
INSERT INTO page_views (page, user_email, views, last_seen)
VALUES ('/home', 'ada@example.com', 1, now())
ON CONFLICT (page, user_email) DO UPDATE
SET views = page_views.views + 1,
last_seen = EXCLUDED.last_seen;