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.
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.
Each module is a set of flashcards — 80 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Domains, constraint triggers, generated columns, and privileges as the schema's public interface
16 cardsValidity periods, temporal keys and PERIOD foreign keys, versioned history tables, and point-in-time reconstruction
16 cardsRead-then-write anomalies, Serializable Snapshot Isolation in practice, and taming write amplification with HOT
16 cardsKeyset pagination, composite key ordering, incrementally maintained aggregates, views as interfaces, and index statistics
16 cardsQueues, pub/sub, cache tables, search and vectors in Postgres — plus capacity estimates and when you really need Kafka or Redis
16 cardsA taste of the real flashcards. Pick an answer, then reveal the explanation.
Why enforce a business invariant in the database rather than only in application code?
What does WITHOUT OVERLAPS do in a PostgreSQL 18 PRIMARY KEY declaration?
What is write skew?
Which requirement genuinely calls for Kafka rather than a queue table in PostgreSQL?
Each card is one practical concept with multiple options. Pick what you think is right.
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
A rule enforced by a constraint or a privilege holds for every service, script and migration — no coordination required.
Write skew and lost updates do not raise errors. Recognizing the read-then-write pattern is what stops silent data corruption.
Validity periods, temporal keys and history tables answer "what did we know, and when" without an event-sourcing stack.
Knowing when Postgres is genuinely enough — and when Kafka or Redis is truly warranted — is a senior-level distinction.
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.
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.
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
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.
Plant your first seed today. Ten minutes a day turns database trivia into design judgment you can defend.