Ошибка	Последствие
Считать индекс бесплатным ускорителем чтения	Упустить цену записи — каждый `INSERT`/`UPDATE` дополнительно правит индекс
Считать, что любой индекс — это B-tree	Промахнуться с типом — `jsonb` и массивам нужен `GIN`, не `B-tree`
Использовать `Hash` для запроса диапазона	`Hash` обслуживает только равенство; диапазон уйдёт в seq scan
Путать нормализацию со сжатием данных	Неверная ментальная модель — это дисциплина проектирования схемы, не storage
Денормализовать преждевременно, без профиля	Усложнённая запись и риск рассинхрона без доказанной выгоды чтения
Думать, что `Read Committed` ловит фантомные чтения	Скрытый баг — фантомы запрещает только `Repeatable Read` и выше
Считать `Serializable` слабейшим уровнем изоляции	Перевёрнутая модель — `Serializable` сильнейший, `Read Uncommitted` слабейший
Считать `SELECT FOR UPDATE` разделяемой блокировкой чтения	Это эксклюзивная блокировка строки на запись — конкурентные писатели ждут
Захватывать строки в разном порядке в разных транзакциях	Взаимоблокировка — каждая транзакция ждёт строку, удерживаемую другой
Думать, что WAL пишется после страниц данных	Перевёрнутый порядок — без записи WAL до данных нет устойчивости и восстановления

intermediate

Databases & PostgreSQL

Indexes, normalization and denormalization, PostgreSQL index types, transaction isolation levels, row locking, and the WAL — seen by a Go backend engineer.

go-databases

Practice: 24 questions · 8 tasks →

Sections

Contents

Detailed explanation

Databases — A Go Backend Is Only as Good as Your Knowledge of the DBMS

A Go service is rarely complex on its own — a goroutine takes a request, queries PostgreSQL, returns a response. All the real difficulty, the whole fight for correctness and performance, lives in how you treat the database. database/sql and pgx give you direct SQL access, but protect you from not a single conceptual mistake: a wrong index, a wrong isolation level, a wrong lock order — all of it compiles, passes local tests, and surfaces only under parallel load.

The traps here are not about syntax. Candidates treat an index as a free read accelerator and forget its cost on every INSERT. They confuse normalization with compression. They think Read Committed saves them from phantom reads. They take SELECT FOR UPDATE believing it is a shared read lock. They expect the application to detect deadlocks itself. This topic dissects the DBMS layer by layer — from how a B-tree works to the write-ahead log — so that each of these interview questions you answer with a mechanism, not a memorised phrase.

Topic Map

Index basics — what an index is, why a B-tree, and the cost it takes on every write.
Normalization — 1NF/2NF/3NF, storing each fact once, and eliminating update anomalies.
PostgreSQL index types — B-tree, Hash, GIN, GiST, BRIN, SP-GiST and the workload each is built for.
Denormalization — deliberate redundancy to cut read-path joins, and its write-side cost.
Transaction isolation — the four levels, the three anomalies, and durability via the WAL.
Document vs relational databases — flexible schema and embedding versus joins, ACID, and referential integrity.
Row locking — SELECT FOR UPDATE, lock acquisition order, and deadlocks.

Common Mistakes and Traps

Mistake	Consequence
Treating an index as a free read accelerator	Missing the write cost — every `INSERT`/`UPDATE` also rewrites the index
Assuming every index is a B-tree	Wrong type — `jsonb` and arrays need `GIN`, not `B-tree`
Using `Hash` for a range query	`Hash` serves equality only; a range falls back to a seq scan
Confusing normalization with data compression	Wrong mental model — it is schema design, not storage
Denormalizing prematurely, with no profile	Complicated writes and desync risk with no proven read benefit
Thinking `Read Committed` prevents phantom reads	Hidden bug — phantoms are forbidden only at `Repeatable Read` and up
Treating `Serializable` as the weakest isolation level	Inverted model — `Serializable` is strongest, `Read Uncommitted` weakest
Treating `SELECT FOR UPDATE` as a shared read lock	It is an exclusive row-level write lock — concurrent writers block
Acquiring rows in different orders across transactions	Deadlock — each transaction waits on a row the other holds
Thinking the WAL is written after the data pages	Inverted order — without writing the WAL first there is no durability

Interview Relevance

Databases are mandatory on any backend interview, and the question is not "do you know the word index" but whether you can reason about cost, correctness, and concurrency.

What interviewers usually check:

What an index is, why a B-tree is the default, and the cost it takes on a write.
Why a schema is normalized — eliminating redundancy and anomalies, not query speed.
When you deliberately denormalize and what you pay for it on the write side.
Which index types PostgreSQL has and which workload each is built for.
The four isolation levels, the three anomalies, and which level forbids what.
What SELECT FOR UPDATE does and why an opposite lock order produces a deadlock.
How a document database differs from a relational one and which guarantees you lose.
How the WAL provides durability and crash recovery.

A typical wrong answer: "Read Committed is the safe level, it protects from all read anomalies." This opens a discussion of how Read Committed forbids only the dirty read, while non-repeatable and phantom reads are still possible on it, and that the choice of level is a conscious trade-off between correctness and concurrency.

Why it matters

A Go backend is almost always a thin layer over a database. If you do not understand what an index costs on a write, which anomalies `Read Committed` lets through, or why two `SELECT FOR UPDATE` statements deadlock, you write code that passes tests and fails in production under concurrency.

Ошибка	Последствие
Считать индекс бесплатным ускорителем чтения	Упустить цену записи — каждый `INSERT`/`UPDATE` дополнительно правит индекс
Считать, что любой индекс — это B-tree	Промахнуться с типом — `jsonb` и массивам нужен `GIN`, не `B-tree`
Использовать `Hash` для запроса диапазона	`Hash` обслуживает только равенство; диапазон уйдёт в seq scan
Путать нормализацию со сжатием данных	Неверная ментальная модель — это дисциплина проектирования схемы, не storage
Денормализовать преждевременно, без профиля	Усложнённая запись и риск рассинхрона без доказанной выгоды чтения
Думать, что `Read Committed` ловит фантомные чтения	Скрытый баг — фантомы запрещает только `Repeatable Read` и выше
Считать `Serializable` слабейшим уровнем изоляции	Перевёрнутая модель — `Serializable` сильнейший, `Read Uncommitted` слабейший
Считать `SELECT FOR UPDATE` разделяемой блокировкой чтения	Это эксклюзивная блокировка строки на запись — конкурентные писатели ждут
Захватывать строки в разном порядке в разных транзакциях	Взаимоблокировка — каждая транзакция ждёт строку, удерживаемую другой
Думать, что WAL пишется после страниц данных	Перевёрнутый порядок — без записи WAL до данных нет устойчивости и восстановления

intermediate

Databases & PostgreSQL

Indexes, normalization and denormalization, PostgreSQL index types, transaction isolation levels, row locking, and the WAL — seen by a Go backend engineer.

go-databases

Practice: 24 questions · 8 tasks →

Sections

Contents

Detailed explanation

Databases — A Go Backend Is Only as Good as Your Knowledge of the DBMS

Topic Map

Index basics — what an index is, why a B-tree, and the cost it takes on every write.
Normalization — 1NF/2NF/3NF, storing each fact once, and eliminating update anomalies.
PostgreSQL index types — B-tree, Hash, GIN, GiST, BRIN, SP-GiST and the workload each is built for.
Denormalization — deliberate redundancy to cut read-path joins, and its write-side cost.
Transaction isolation — the four levels, the three anomalies, and durability via the WAL.
Document vs relational databases — flexible schema and embedding versus joins, ACID, and referential integrity.
Row locking — SELECT FOR UPDATE, lock acquisition order, and deadlocks.

Common Mistakes and Traps

Mistake	Consequence
Treating an index as a free read accelerator	Missing the write cost — every `INSERT`/`UPDATE` also rewrites the index
Assuming every index is a B-tree	Wrong type — `jsonb` and arrays need `GIN`, not `B-tree`
Using `Hash` for a range query	`Hash` serves equality only; a range falls back to a seq scan
Confusing normalization with data compression	Wrong mental model — it is schema design, not storage
Denormalizing prematurely, with no profile	Complicated writes and desync risk with no proven read benefit
Thinking `Read Committed` prevents phantom reads	Hidden bug — phantoms are forbidden only at `Repeatable Read` and up
Treating `Serializable` as the weakest isolation level	Inverted model — `Serializable` is strongest, `Read Uncommitted` weakest
Treating `SELECT FOR UPDATE` as a shared read lock	It is an exclusive row-level write lock — concurrent writers block
Acquiring rows in different orders across transactions	Deadlock — each transaction waits on a row the other holds
Thinking the WAL is written after the data pages	Inverted order — without writing the WAL first there is no durability

Interview Relevance

Databases are mandatory on any backend interview, and the question is not "do you know the word index" but whether you can reason about cost, correctness, and concurrency.

What interviewers usually check:

What an index is, why a B-tree is the default, and the cost it takes on a write.
Why a schema is normalized — eliminating redundancy and anomalies, not query speed.
When you deliberately denormalize and what you pay for it on the write side.
Which index types PostgreSQL has and which workload each is built for.
The four isolation levels, the three anomalies, and which level forbids what.
What SELECT FOR UPDATE does and why an opposite lock order produces a deadlock.
How a document database differs from a relational one and which guarantees you lose.
How the WAL provides durability and crash recovery.

Why it matters

Базы данных и PostgreSQL

Базы данных — backend на Go живёт ровно настолько хорошо, насколько вы знаете СУБД

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Databases & PostgreSQL

Databases — A Go Backend Is Only as Good as Your Knowledge of the DBMS

Topic Map

Common Mistakes and Traps

Interview Relevance

Базы данных и PostgreSQL

Базы данных — backend на Go живёт ровно настолько хорошо, насколько вы знаете СУБД

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Databases & PostgreSQL

Databases — A Go Backend Is Only as Good as Your Knowledge of the DBMS

Topic Map

Common Mistakes and Traps

Interview Relevance