A guild is everyone in the club who runs one family of engines. A Special Interest Group is the smaller room inside it, where the members who carry the pager for one platform meet to write things down: runbooks, drill scripts, upgrade decisions and reference designs the rest of the club can use.
There are ten SIGs: one each for PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2, MongoDB, ClickHouse and Redis, and one for the managed cloud database services that run underneath all of them. Each SIG sits inside a guild, follows the same charter and keeps its work in the reading room.
The ten SIGs
Each card opens that SIG’s charter on this page. The reference links go to MinervaDB’s public page for the platform.
PostgreSQL SIG
Vacuum and wraparound, Patroni HA, logical replication, major-version upgrades.
MySQL SIG
InnoDB internals, Group Replication, online schema change, life after 8.0.
ClickHouse SIG
MergeTree design, ingestion at scale, Keeper, object-storage tiering.
Redis SIG
Memory and eviction, persistence, Cluster and Sentinel, Redis or Valkey.
Cloud DBaaS SIG
Managed or self-managed, shared responsibility, FinOps, cross-cloud DR.
How a SIG works
- Who joins. Any guild member who runs the platform in production, at any title. Circle members join on the same terms. Most members sit on one or two SIGs.
- Two SIG leads. Elected by the SIG at the guild founding sessions in November 2026, for a year. The steward rule applies: a lead may not hold a sales or pre-sales role anywhere.
- The working session. Sixty minutes online each month, in a week the guild does not meet. One artefact on the table every time: a runbook, a drill result, an upgrade plan or a post-mortem.
- Labs at the conferences. Where a GCC Leadership Conference runs a lab track, the SIGs run it: failovers, upgrades and restores on throwaway clusters, not slides.
- Outputs go to the reading room. Every output names the engine and version, is reviewed by two members who did not write it, and carries a date so stale guidance is easy to spot.
- The charter applies in full. No selling. Chatham House, with one strike. Customer names never appear in a session or an output.
On the reference links. fsyncDATA is a GCC club of MinervaDB Inc. Each SIG links to MinervaDB’s public page for that platform so members have a practitioner reference to read and argue with. SIG sessions are not a sales channel for MinervaDB or anyone else.
Inside the PostgreSQL Guild
PostgreSQL SIG
For the people who own PostgreSQL estates where a missed freeze is an outage, not a slow afternoon. The SIG works on the failure modes that only show up at size: tables that outgrow autovacuum defaults, replication slots that quietly hold WAL, and upgrades that have to finish inside a maintenance window someone else agreed to.
Inside the MySQL and MariaDB Guild
MySQL SIG
For teams running MySQL at the volume where InnoDB settings stop being defaults and start being decisions. With MySQL 8.0 past end of life since April 2026, much of the first year is about moving estates to 8.4 LTS without surprises.
Inside the MySQL and MariaDB Guild
MariaDB SIG
For teams that run MariaDB as MariaDB, not as an older MySQL. The two engines have diverged far enough that GTIDs, JSON handling, optimizer behaviour and replication between them all need their own notes, and this SIG keeps them.
Inside the SQL Server Guild
SQL Server SIG
For the people who run SQL Server where licensing, plan stability and availability groups decide most of the architecture. With SQL Server 2016 out of extended support since July 2026 and 2017 following in October 2027, upgrade and migration plans are on most agendas.
Inside the Oracle, Db2 and SAP HANA Guild
Oracle SIG
For the people who keep Oracle estates patched, protected and inside their licence. The SIG treats the licence boundary as a technical constraint, because a diagnostic query run in the wrong place can cost more than the hardware it runs on.
Inside the Oracle, Db2 and SAP HANA Guild
Db2 SIG
For the people running Db2 in banks, insurers and manufacturers, on LUW and on z/OS. Two communities that rarely share a room share this one, because HADR, monitoring and offload problems look more alike across them than the platforms suggest.
Inside the NoSQL Guild
MongoDB SIG
For teams whose MongoDB estates have outgrown their first shard key. The SIG works on the choices that are expensive to undo: how data is partitioned, what durability the application actually asked for, and where the cluster should run.
Inside the Real-time Analytics Guild
ClickHouse SIG
For teams running ClickHouse where queries land in milliseconds and ingestion never stops. Most production trouble starts with a sort key or a part count, so the SIG starts there and reads system tables before it reads dashboards.
Inside the Redis and Valkey Guild
Redis SIG
For teams whose caches have quietly become systems of record. Valkey operators are as welcome as Redis operators: the SIG covers both, and the choice between them since the 2024 licence change.
Across every guild
Cloud DBaaS SIG
For the people who answer for managed databases on AWS, Azure and Google Cloud, and for vendor clouds such as Snowflake, Databricks and MongoDB Atlas. This SIG draws members from every guild, because the questions are the same whichever engine sits underneath: who owns the failure, what the bill is doing, and whether the DR plan has ever run.
Propose a SIG
The guilds also cover SAP HANA, Apache Cassandra, Amazon DynamoDB, YugabyteDB, CockroachDB, Trino, Vertica, Milvus and the cloud warehouses. A SIG for any of them opens when ten guild members ask for it and two agree to lead it. Write to the secretariat at shiv@minervadb.com.
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.