In addition to @Ninigi’s suggestion, you can avoid race conditions using locking:

Query.lock to lock a record during a transaction:

Repo.transaction(fn -> 
  post = 
    Post
    |> where(id: 42)
    |> lock("FOR UPDATE")
    |> Repo.one()

  changeset = Ecto.Changeset.change post, title: “New title”
  ... 
end)

Or Changeset.optimistic_lock to use a version field to detect races:

post = MyRepo.get!(Post, 42)
post = 
  post
  |> Changeset.change(title: “New title”)
  |> Changeset.optimistic_lock(:version)

case MyRepo.update post do
  {:ok, struct} -> # Updated with success
  {:error, changeset} -> # Something went wrong
end

If you want to use changesets to validate your changes before firing the database update, then yes, you need to load it first.

If you are willing to skip changesets, then you can use Repo.update_all/3.

{1, [updated_post]} =
  from(p in Post, where: p.id == 42, select: p)
  |> MyRepo.update_all(set: [title: "New title"])

This will fire a query that looks something like this

UPDATE "posts" AS p0 SET "title" = $1 WHERE (p0."id" = 42) RETURNING p0."id" ... ['New title']

Not all databases support the returning option, I know for a fact that postgresql does, but not sure about other databases.

EDIT: @mbuhot has a nicer solution that would not skip the changeset. Running the update in one database query might have its applications, but in this particular use-case I’d suggest his solution instead of mine.

you can also try to use Ecto.Multi — Ecto v3.14.0