Yes, you can observe this with debug logging:

iex(5)> %Menu.Item{name: "Bar", price: 4.50, category: %Menu.Category{name: "Foo"}} |> Repo.insert!
[debug] QUERY OK db=0.3ms
begin []
[debug] QUERY OK db=6.6ms
INSERT INTO "categories" ("name","inserted_at","updated_at") VALUES ($1,$2,$3) RETURNING "id" ["Foo", {{2017, 11, 3}, {20, 21, 34, 814485}}, {{2017, 11, 3}, {20, 21, 34, 817077}}]
[debug] QUERY OK db=5.0ms
INSERT INTO "items" ("category_id","name","price","inserted_at","updated_at") VALUES ($1,$2,$3,$4,$5) RETURNING "id" [4, "Bar", #Decimal<4.5>, {{2017, 11, 3}, {20, 21, 34, 834005}}, {{2017, 11, 3}, {20, 21, 34, 834009}}]
[debug] QUERY OK db=0.8ms
commit []

Note the begin and commit lines. Those are the beginning and end of the transaction respectively.

If anyone coming to this topic needs more tips on Ecto.Multi and transactions in general, we’ve written a post about it: How database transactions work in Ecto and why Elixir makes it awesome?

You probably want an Ecto.Multi rather than using transactions directly as you get a bunch of extra stuff that you don’t get with Repo.transaction

Well, since I don’t know what I get with transactions, I’d really like to understand more about them first, so I can understand what advantages I’m getting with Ecto.Multi.

A transaction is a sequence of operations performed as a single unit of work. Or more simply, if a statement in the transaction fails the previous statements will get automatically rolled back (in Ecto), and no further operations are carried out. If you’re using transactions manually you can perform special behaviours on rollback, if simply rolling back isn’t enough.

Ecto.Multi works hand in hand with Repo.transaction and provides a bunch of useful stuff on top of transactions. i.e. easy inspection and returns, that using Repo.transaction directly you’d probably end up implementing anyway.