Databases · 5 modules

PostgreSQL Advanced

Design decisions, not syntax. Learn to push invariants into the schema, model time and audit trails, survive write skew, and judge when Postgres alone replaces a queue, cache or search cluster — remembered with spaced repetition.

flashcards
80
flashcards
per day
~10 min
per day
level
Advanced
level
modules
5
modules
About this topic

What this track is for

Most PostgreSQL material stops at "here is the syntax". This track starts where that ends: it is about the judgment calls — which invariant belongs in the schema rather than in a service, when a constraint has to be deferred to commit, what a read-then-write trigger silently corrupts under READ COMMITTED, and how much infrastructure you are adding to solve a problem you never measured.

The through-line is that a database can carry far more of a system's design than most teams ask of it. Domains, constraint triggers and column-level grants turn business rules into properties of the data. Validity periods, temporal keys and versioned history tables give you an audit trail and point-in-time reconstruction without an event store. Serializable Snapshot Isolation makes concurrent ledger updates provably correct, while HOT updates and fillfactor keep the write amplification that follows under control.

It assumes the PostgreSQL in Practice track (or equivalent experience): you should already be comfortable with indexes, EXPLAIN, MVCC and vacuum. Five modules, spaced repetition, and every card written around a decision you will actually have to defend in a design review.

What you'll learn

5 modules, seed to bloom

Each module is a set of flashcards — 80 in total. Answer, review, and watch your knowledge grow from seed to full bloom.

Constraints & Integrity

Domains, constraint triggers, generated columns, and privileges as the schema's public interface

16 cards

Temporal Data & Audit Trails

Validity periods, temporal keys and PERIOD foreign keys, versioned history tables, and point-in-time reconstruction

16 cards

Write Skew, SSI & HOT Updates

Read-then-write anomalies, Serializable Snapshot Isolation in practice, and taming write amplification with HOT

16 cards

Query Design Patterns

Keyset pagination, composite key ordering, incrementally maintained aggregates, views as interfaces, and index statistics

16 cards

Postgres as a Platform

Queues, pub/sub, cache tables, search and vectors in Postgres — plus capacity estimates and when you really need Kafka or Redis

16 cards
Try before you plant

Sample questions

A taste of the real flashcards. Pick an answer, then reveal the explanation.

Sample · PostgreSQL Advanced

Why enforce a business invariant in the database rather than only in application code?

  • AEvery client and code path is covered — no service, script, or migration can write around the rule
  • BThe rule runs faster than in the application — the planner rewrites the check into an index scan
  • CThe rule can be changed without a migration — constraints are metadata and skip the DDL path
  • DThe rule removes the need for transactions — constraint checks take the locks that writers need
Permalink & share
Sample · PostgreSQL Advanced

What does WITHOUT OVERLAPS do in a PostgreSQL 18 PRIMARY KEY declaration?

  • AThe last column is compared for overlap rather than equality, so a key may repeat over disjoint periods
  • BThe last column is dropped from the key itself and carried in the index only as a payload for scans
  • CThe key stops enforcing uniqueness altogether and rejects a row only when two periods are identical
  • DThe key forces an ordering on that column so the index accepts periods in ascending sequence only
Permalink & share
Sample · PostgreSQL Advanced

What is write skew?

  • ATwo transactions read overlapping data and then write different rows, leaving a state no serial order allows
  • BTwo transactions write the very same row, and the commit that lands second silently discards the first value
  • COne transaction reads a row twice and sees two different values because another commit landed in between
  • DOne transaction reads rows another has written but not committed, and keeps that result after the rollback
Permalink & share
Sample · PostgreSQL Advanced

Which requirement genuinely calls for Kafka rather than a queue table in PostgreSQL?

  • AIndependent consumer groups replaying a retained, ordered log at sustained high throughput
  • BA single worker pool draining tasks reliably, where each task must be handled exactly once
  • CA handful of background jobs that have to run in order and survive an application restart
  • DA flow where the producer needs to learn whether a consumer finished handling its message
Permalink & share
How Gnoseed works

Learn it once, keep it for good

1

Answer a question

Each card is one practical concept with multiple options. Pick what you think is right.

2

Get the full answer

See the correct option plus a clear explanation, and a link to deeper docs when one is available.

3

Review at the right time

A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.

Why learn this

Why this material is worth your time

Invariants that cannot be bypassed

A rule enforced by a constraint or a privilege holds for every service, script and migration — no coordination required.

The anomalies nobody sees

Write skew and lost updates do not raise errors. Recognizing the read-then-write pattern is what stops silent data corruption.

Time as a first-class column

Validity periods, temporal keys and history tables answer "what did we know, and when" without an event-sourcing stack.

Architecture you can defend

Knowing when Postgres is genuinely enough — and when Kafka or Redis is truly warranted — is a senior-level distinction.

FAQ

Common questions

Should I do the PostgreSQL in Practice track first? +

Yes, if the basics are not solid yet. This track assumes you already know index kinds, EXPLAIN, MVCC and vacuum, and builds one level deeper on top of them.

Which PostgreSQL version does it assume? +

Modern, currently supported releases. Most of the material is version-stable; the notable exception is temporal keys — PRIMARY KEY … WITHOUT OVERLAPS and PERIOD foreign keys arrived in PostgreSQL 18, and the Temporal Data module teaches them as such.

Is it free? +

Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.

Is this only useful if I run Postgres at scale? +

No. Much of it is about avoiding scale you do not need — capacity estimates, benchmarking against the real requirement, and the queue, pub/sub and search patterns that keep a single database sufficient for longer than most teams assume.

Ready to push PostgreSQL further?

Plant your first seed today. Ten minutes a day turns database trivia into design judgment you can defend.

Start learning free