Database Engineering Interview Questions
Database rounds rarely test whether you can write a JOIN. They test whether you can keep data correct under concurrency, retries, replication lag, and live schema change: a transaction that stays balanced when a write fails midway, a reservation that never oversells, a query whose plan stays bounded when one tenant’s volume explodes. Gronex lets you practice those exact failures in real PostgreSQL repositories with failing tests, so you rehearse the round rather than memorise trivia.
What database engineering interviews test
The hard part of a database role is not the query language — it is correctness under real-world messiness. A refund workflow that fails halfway must not leave the ledger unbalanced. Two concurrent reservations must not both succeed against the last unit of stock. A recent writer must see its own write even after reads move to a replica. And a migration must not lose rows while the table keeps taking traffic. These are the bugs that ship to production and page the on-call engineer, and they are exactly what a good interviewer probes.
Every challenge here is a real repository backed by PostgreSQL with a bundled verify step. You fix the schema, query, or transaction until the invariants hold — balances reconcile, stock stays non-negative, plans stay bounded, and replays converge. The scenarios run in seconds against a local database baked into the image, with no cluster to stand up.
Common patterns in database rounds
Transactions & isolation
Grouping related mutations so a failure or retry never exposes partial state — the difference between a balanced ledger and a phantom refund.
Concurrency & locking
Placing the decision next to the protected row so lost updates and oversells cannot happen, without serialising the whole service.
Idempotency
Letting a database uniqueness constraint arbitrate duplicate requests so a client retry resolves to one durable outcome.
Indexing & query plans
Reading EXPLAIN, designing composite indexes, and proving partition pruning so the plan touches bounded storage under load.
Pagination & scaling
Stable keyset traversal and tenant-aware partitioning that stay bounded as the dataset and its skew grow.
Replication & migrations
Session-aware read-after-write routing and expand-contract migrations that stay correct while data changes underneath them.
Problems to practice
Each is a real repository with a failing test suite over a live PostgreSQL database. Open the brief and fix it — no signup required to read the full problem.
Connection Pool Exhausts After Failed Requests
A short run of failed lookups drains every pooled connection; sessions return idle-in-transaction. Restore lifecycle hygiene on both success and exception paths.
Open the challenge →Database Overload Under a Traffic Spike
A missing index, N+1 queries, and unbounded fetches saturate PostgreSQL under load. Bound the work per page and prove it with query plans.
Open the challenge →One Tenant's Volume Slows Every Tenant
Tenant reads fail partition pruning, so one hot customer scans everyone else’s data. Make the tenant boundary prunable.
Open the challenge →Inventory Overselling Under Concurrency
A read-decide-write race oversells stock and duplicates reservations on retry. Enforce stock conservation and idempotency in one transaction.
Open the challenge →Catalog Pagination Skips and Repeats Products
LIMIT/OFFSET drifts under concurrent inserts and scans deeply. Move to stable keyset pagination with a deterministic tie-breaker.
Open the challenge →Payment Ledger Consistency
Separate writes leave the double-entry ledger unbalanced or double-refunded. Make the multi-row invariant atomic and retry-safe.
Open the challenge →Read Replica Serves Stale Data After a Write
A writer immediately reads a lagging replica and misses its own order. Add a session watermark that falls back to primary only while lag matters.
Open the challenge →Outbox Publishes Phantom and Duplicate Events
Business and outbox writes cross commit boundaries; concurrent publishers double-deliver. Make writes atomic and claims safe.
Open the challenge →Zero-Downtime Column Split Loses Rows
An expand-contract backfill skips users and the live writer ignores new columns. Dual-write and gate completion on data state, not cursor position.
Open the challenge →CDC Search Index Synchronization
A change-stream projector exposes rolled-back rows, retains deletes, and duplicates on replay. Apply create/update/delete idempotently with a durable cursor.
Open the challenge →