By default, Postgres executes transactions in unchained mode (also known as "autocommit" in other database systems). In other words, each user statement is executed in its own transaction and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done). BEGIN initiates a user transaction in chained mode, i.e., all user statements after BEGIN command will be executed in a single transaction until an explicit COMMIT, ROLLBACK, or execution abort. Statements in chained mode are executed much faster, because transaction start/commit requires significant CPU and disk activity. Execution of multiple statements inside a transaction is also required for consistency when changing several related tables.
The default transaction isolation level in Postgres is READ COMMITTED, where queries inside the transaction see only changes committed before query execution. So, you have to use SET TRANSACTION ISOLATION LEVEL SERIALIZABLE just after BEGIN if you need more rigorous transaction isolation. In SERIALIZABLE mode queries will see only changes committed before the entire transaction began (actually, before execution of the first DML statement in a serializable transaction).
If the transaction is committed, Postgres will ensure either that all updates are done or else that none of them are done. Transactions have the standard ACID (atomic, consistent, isolatable, and durable) property.
BEGIN is a Postgres language extension. There is no explicit BEGIN command in SQL92; transaction initiation is always implicit and it terminates either with a COMMIT or ROLLBACK statement.
Note: Many relational database systems offer an autocommit feature as a convenience.
Incidentally, the BEGIN keyword is used for a different purpose in embedded SQL. You are advised to be careful about the transaction semantics when porting database applications.
SQL92 also requires SERIALIZABLE to be the default transaction isolation level.