Replace database brief with PostgreSQL and Redis briefs

.agents/skills/quiz/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: quiz
-description: Run an interactive interview quiz from the topic briefs in docs/topics/. Use when the user asks to be quizzed or tested on a topic, e.g. "/quiz golang", "/quiz ethereum database", "/quiz all 20".
+description: Run an interactive interview quiz from the topic briefs in docs/topics/. Use when the user asks to be quizzed or tested on a topic, e.g. "/quiz golang", "/quiz ethereum postgresql", "/quiz all 20".
 argument-hint: "<all | topic [topic...]> [count]"
 ---
 

.agents/skills/renovate/SKILL.md

@@ -31,7 +31,7 @@ Without subagents, do the topics one after another. Wait until every topic has r
 Your training data is older than the latest releases. Take versions, dates, and behavior from current official sources (release notes, changelogs, spec or EIP pages, the project blog, docs via Context7), not from memory. Every change you make needs a source you have actually read in this session.
 
 1. Read `AGENTS.md` (format rules, what to include and cut, topic ownership) and the whole brief.
-2. Inventory what is versioned. List the subjects the brief depends on (e.g. ethereum: protocol forks, EIPs, client defaults; nextjs: Next.js, React; database: PostgreSQL, MySQL, Redis, PgBouncer) and every version-bound claim: `since X`, `X+`, version numbers, dates, "experimental", "deprecated", "default", "planned", "upcoming", and numbers that change between releases (limits, defaults, prices, thresholds). Fundamentals briefs (algorithms, distributed, system) have few of these; check the tools and products they name.
+2. Inventory what is versioned. List the subjects the brief depends on (e.g. ethereum: protocol forks, EIPs, client defaults; nextjs: Next.js, React; postgresql: PostgreSQL, PgBouncer) and every version-bound claim: `since X`, `X+`, version numbers, dates, "experimental", "deprecated", "default", "planned", "upcoming", and numbers that change between releases (limits, defaults, prices, thresholds). Fundamentals briefs (algorithms, distributed, system) have few of these; check the tools and products they name.
 3. Find the latest stable release of each subject and the newest version the brief mentions. Read the release notes for every version in between. Prereleases (beta, RC, nightly, draft EIPs, proposals) don't count as shipped. Mention one only when the brief already does, or when interviewers already ask about it, and label it with its status (e.g. "planned for Fusaka", "TypeScript 7 beta").
 4. Check the brief's claims and prose against the sources, starting with the inventory from step 2, and fix what is wrong, stale, or misleading. Keep historical version distinctions that are still useful ("before Go 1.22"). Look in particular for:
    - an experimental or opt-in feature that is now the default or removed;

AGENTS.md

@@ -79,24 +79,25 @@ Keep facts that a working engineer knew once but loses without daily use:
 
 ## Topic ownership
 
-Each concept has one owner file that covers it in full. Other files may overlap where the concept matters to them too: a bullet or a short concept stating what matters from their angle (database says the WAL is only durable after `fsync`; os explains `fsync`), with a link to the owner for the rest. Don't copy the owner's concept wholesale — copies drift apart, and the quiz would ask the same question twice.
+Each concept has one owner file that covers it in full. Other files may overlap where the concept matters to them too: a bullet or a short concept stating what matters from their angle (postgresql says the WAL is only durable after `fsync`; os explains `fsync`), with a link to the owner for the rest. Don't copy the owner's concept wholesale — copies drift apart, and the quiz would ask the same question twice.
 
 | Concept | Owner | Referenced from |
 |---|---|---|
-| Consistency models, replication theory, consensus, clocks (monotonic vs wall), delivery semantics, sagas, CRDTs, CDC | distributed | database, system, backend, os, golang |
+| Consistency models, replication theory, consensus, clocks (monotonic vs wall), delivery semantics, sagas, CRDTs, CDC | distributed | postgresql, redis, system, backend, os, golang |
 | Retries, backoff, circuit breakers, backpressure, tail latency | distributed | backend, system |
-| Isolation levels, MVCC, indexes, WAL, DB replication setup, pooling | database | backend, system |
-| Caching strategies, rate-limiting algorithms, load balancing, CDN, observability (SLI/SLO), capacity math (Little's law), multi-region and DR tiers | system | backend, devops, os, aws |
-| REST/gRPC/GraphQL, pagination, idempotency keys, outbox, graceful shutdown, N+1, schema evolution, multi-tenancy, time handling | backend | system, database, distributed |
+| Isolation levels, MVCC, indexes, WAL, DB replication setup, pooling, SQL | postgresql | backend, system, devops |
+| Redis execution model, data structures, eviction, persistence, Sentinel and Cluster, streams | redis | system, distributed |
+| Caching strategies, rate-limiting algorithms, load balancing, CDN, observability (SLI/SLO), capacity math (Little's law), multi-region and DR tiers, storage engines (B-tree vs LSM), search and OLAP stores | system | backend, devops, os, aws, postgresql, redis |
+| REST/gRPC/GraphQL, pagination, idempotency keys, outbox, graceful shutdown, N+1, schema evolution, multi-tenancy, time handling | backend | system, postgresql, distributed |
 | AuthN, sessions, OAuth/OIDC, JWT, XSS, CSRF, CORS, clickjacking, crypto, TLS | security | backend, frontend, nextjs |
-| Containers, Kubernetes, cloud, IaC, deployment strategies, zero-downtime migrations | devops | backend, database |
+| Containers, Kubernetes, cloud, IaC, deployment strategies, zero-downtime migrations | devops | backend, postgresql |
 | Browser event loop, JS language semantics | javascript | frontend, typescript |
 | Rendering strategies, browser pipeline, Web Vitals, HTTP caching in the browser, browser storage | frontend | javascript, security, react, nextjs |
 | React rendering model, hooks, client state management, Suspense and transitions, Server Components and Server Functions, hydration | react | frontend, nextjs |
 | Next.js App Router, rendering and caching layers, `use cache`, routing conventions, Server Actions configuration, proxy, self-hosting | nextjs | react, frontend |
 | asyncio event loop | python | — |
 | TCP/UDP, HTTP versions, QUIC, DNS, IP addressing, NAT, MTU, BGP/anycast | networking | backend, system, devops |
-| Processes, signals, scheduling, virtual memory, OOM, file descriptors, epoll/io_uring, fsync, locks | os | devops, database, golang |
+| Processes, signals, scheduling, virtual memory, OOM, file descriptors, epoll/io_uring, fsync, locks | os | devops, postgresql, redis, golang |
 | Container internals (namespaces, cgroups), Kubernetes graceful shutdown | devops | os, backend |
 | Solidity language, storage layout, calls and ABI, contract security, gas optimization, upgradeability | solidity | ethereum |
 | EVM execution, gas and fee market, transaction types, signatures and token standards, DeFi (flash loans, oracle manipulation) and MEV | ethereum | solidity |

README.md

@@ -11,7 +11,6 @@ Each topic in `docs/topics/` is a brief grouped by subtopic, covering what an ex
 ### Fundamentals
 
 - [Algorithms](docs/topics/algorithms.md) — complexity, arrays and sequences, strings, sorting, data structures, graphs, dynamic programming, greedy and backtracking, NP-hardness
-- [Databases](docs/topics/database.md) — indexes, isolation, MVCC and locking, storage engines, query tuning, SQL gotchas, Redis and NoSQL, schema design, scaling
 - [Distributed Systems](docs/topics/distributed.md) — theory, consistency models, replication, partitioning, consensus, clocks and IDs, transactions, conflict resolution, failure handling, Kafka and stream processing
 - [Networking](docs/topics/networking.md) — TCP, keepalive and congestion control, HTTP/1.1 vs 2 vs 3, QUIC, DNS, IP addressing, NAT, MTU, BGP and anycast
 - [Operating Systems](docs/topics/os.md) — processes and signals, scheduling and cgroup throttling, virtual memory, OOM and cgroup limits, NUMA, file descriptors, epoll and io_uring, fsync, synchronization, perf tools
@@ -38,6 +37,8 @@ Each topic in `docs/topics/` is a brief grouped by subtopic, covering what an ex
 
 - [AWS](docs/topics/aws.md) — IAM and KMS, VPC networking, compute, storage and databases, events, operations
 - [DevOps](docs/topics/devops.md) — deployment strategies, containers, Kubernetes workloads/storage/networking/operations, Terraform, CI/CD and GitOps
+- [PostgreSQL](docs/topics/postgresql.md) — indexes, isolation, MVCC and VACUUM, locking and schema changes, query tuning, SQL gotchas, WAL and backups, replication, pooling and partitioning, schema design
+- [Redis](docs/topics/redis.md) — execution model, transactions and scripts, data structures, expiration and eviction, persistence, replication and Sentinel, Cluster, pub/sub and streams, locks and counters
 
 ### Domains
 

docs/index.md

@@ -7,7 +7,6 @@ Topic briefs on what engineers forget before technical interviews, grouped by su
 ### Fundamentals
 
 - [Algorithms](topics/algorithms.md) — complexity, arrays and sequences, strings, sorting, data structures, graphs, dynamic programming, greedy and backtracking, NP-hardness
-- [Databases](topics/database.md) — indexes, isolation, MVCC and locking, storage engines, query tuning, SQL gotchas, Redis and NoSQL, schema design, scaling
 - [Distributed Systems](topics/distributed.md) — theory, consistency models, replication, partitioning, consensus, clocks and IDs, transactions, conflict resolution, failure handling, Kafka and stream processing
 - [Networking](topics/networking.md) — TCP, keepalive and congestion control, HTTP/1.1 vs 2 vs 3, QUIC, DNS, IP addressing, NAT, MTU, BGP and anycast
 - [Operating Systems](topics/os.md) — processes and signals, scheduling and cgroup throttling, virtual memory, OOM and cgroup limits, NUMA, file descriptors, epoll and io_uring, fsync, synchronization, perf tools
@@ -34,6 +33,8 @@ Topic briefs on what engineers forget before technical interviews, grouped by su
 
 - [AWS](topics/aws.md) — IAM and KMS, VPC networking, compute, storage and databases, events, operations
 - [DevOps](topics/devops.md) — deployment strategies, containers, Kubernetes workloads/storage/networking/operations, Terraform, CI/CD and GitOps
+- [PostgreSQL](topics/postgresql.md) — indexes, isolation, MVCC and VACUUM, locking and schema changes, query tuning, SQL gotchas, WAL and backups, replication, pooling and partitioning, schema design
+- [Redis](topics/redis.md) — execution model, transactions and scripts, data structures, expiration and eviction, persistence, replication and Sentinel, Cluster, pub/sub and streams, locks and counters
 
 ### Domains
 

docs/topics/algorithms.md

@@ -1,6 +1,6 @@
 # Algorithms
 
-What experienced engineers forget before an algorithms interview, grouped by subtopic. Bounds follow [MIT 6.006](https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/), [Princeton Algorithms](https://algs4.cs.princeton.edu/), and the [USACO Guide](https://usaco.guide/). For database indexes see [database.md](database.md); for rate limiting and load balancing see [system.md](system.md); for consensus see [distributed.md](distributed.md).
+What experienced engineers forget before an algorithms interview, grouped by subtopic. Bounds follow [MIT 6.006](https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/), [Princeton Algorithms](https://algs4.cs.princeton.edu/), and the [USACO Guide](https://usaco.guide/). For database indexes see [postgresql.md](postgresql.md); for rate limiting and load balancing see [system.md](system.md); for consensus see [distributed.md](distributed.md).
 
 ## Complexity and problem solving
 

docs/topics/aws.md

@@ -1,6 +1,6 @@
 # AWS
 
-What experienced AWS developers and DevOps engineers forget before an interview, grouped by subtopic; facts follow the AWS documentation. For database internals see [database.md](database.md); for delivery semantics and retries see [distributed.md](distributed.md); for deployment patterns and Terraform see [devops.md](devops.md).
+What experienced AWS developers and DevOps engineers forget before an interview, grouped by subtopic; facts follow the AWS documentation. For PostgreSQL and Redis internals see [postgresql.md](postgresql.md) and [redis.md](redis.md); for delivery semantics and retries see [distributed.md](distributed.md); for deployment patterns and Terraform see [devops.md](devops.md).
 
 ## Identity and access
 

docs/topics/backend.md

@@ -1,6 +1,6 @@
 # Backend
 
-What experienced backend engineers forget before an interview, grouped by subtopic. For database internals see [database.md](database.md); for queues, sagas, and retries see [distributed.md](distributed.md); for caching and rate limiting see [system.md](system.md); for HTTP versions see [networking.md](networking.md); for auth and vulnerabilities see [security.md](security.md).
+What experienced backend engineers forget before an interview, grouped by subtopic. For PostgreSQL internals see [postgresql.md](postgresql.md); for Redis see [redis.md](redis.md); for queues, sagas, and retries see [distributed.md](distributed.md); for caching and rate limiting see [system.md](system.md); for HTTP versions see [networking.md](networking.md); for auth and vulnerabilities see [security.md](security.md).
 
 ## API design
 
@@ -123,7 +123,7 @@ What experienced backend engineers forget before an interview, grouped by subtop
 ### Connection pool sizing
 
 - Size the [connection pool](https://en.wikipedia.org/wiki/Connection_pool) from the database's capacity, not the app's thread count — many app instances × a large pool overwhelm the database.
-- A good starting point is a small pool per instance (~2× DB cores total across instances, [HikariCP's formula](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)), then measure wait time; see [database.md](database.md).
+- A good starting point is a small pool per instance (~2× DB cores total across instances, [HikariCP's formula](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)), then measure wait time; server-side pooling in [postgresql.md](postgresql.md).
 
 ### Transaction boundaries