The curriculum is not a syllabus. It is the set of decisions GCC data teams will face in the next eighteen months, worked through by the people facing them.
Each theme runs at two altitudes: as a Circle working session on the decision, and as guild sessions on how each engine handles it. What you leave with is something to act on Monday: a query to run on your own estate, a question for your vendor, a design you will not repeat, or a peer to call.
Ten themes for year one
| Theme | The decision (Circle) | The engineering (Guilds) | When it bites |
|---|---|---|---|
| End-of-support calendar | What is forced, what is optional, what to fund | Upgrade paths and test plans per engine, for example PostgreSQL 14 reaching end of life in November 2026 and SQL Server 2017 extended support ending in October 2027 | Q4 2026 to Q4 2027 |
| Cost of the data layer | Why database and warehouse spend grows faster than data, and how estates reversed it | Right-sizing, reserved capacity, storage tiering, query cost per engine | Every renewal and commit |
| Reliability and DR | What RPO and RTO the business actually needs, and who pays for it | Failover drills, restore tests, replica topology per engine | Every quarter |
| Performance at scale | Where to spend engineering time first | Plans, waits, indexing, partitioning, connection pooling | Every month-end and peak |
| Engine consolidation | How many engines an estate should run, and which to retire | Migration patterns: Oracle and SQL Server to PostgreSQL, warehouse to lakehouse, Redis to Valkey | Every architecture review |
| Managed vs self-managed | When DBaaS is cheaper and when it is not | What RDS, Aurora, Azure SQL, Cloud SQL and AlloyDB change about operations and failure modes | Every new platform |
| DPDP obligations | Retention, erasure, breach telemetry and residency design | Audit logging, masking, row and column security per engine | 13 May 2027 |
| AI data foundations | What AI charters are quietly waiting on | Vector search, CDC and streaming, lineage and freshness | Every AI programme review |
| Talent and attrition | What keeps a senior DBA in a center | Career ladders for DBREs and database engineers, on-call design | Every quarter |
| The HQ relationship | How centers earn a seat at the parent’s platform council | Evidence packs: SLOs met, incidents closed, cost saved | Every budget cycle |
Six formats, one membership
Guild session
Sixty minutes, online, per guild. One member presents a real incident, migration or design.
Working session
Ninety minutes, online, capped at forty. One leader brings one decision with its numbers.
Deep dive
Half a day in one city and online. Circle and guild members at one table, then dinner.
Office hours
One hour with principal engineers. Nothing is scoped, quoted or followed up.
Peer bench
A question routed to three members who run that engine. Answers within 48 hours.
Reading room
Summaries, post-mortems, runbooks and reference designs, anonymised, searchable by engine.
How a session works
A guild session runs sixty minutes: twenty of story, thirty of questions from the guild, ten of what the guild would do. Engine and version are named; the customer never is.
A Circle working session runs ninety minutes: twenty of story, forty of questions, thirty of what the room would do. No slides beyond the numbers.
Both end in a one-page summary, anonymised, in the reading room the next day.
Apply, ask, or nominate someone better
Practitioners apply to a Guild. Leaders request a Circle invitation. Anyone may nominate a peer. Every message to the secretariat is answered by a person within two working days.