A guild is the members who run one family of engines, whatever cloud or console it sits behind. Ten guilds cover 28 engines and cloud database services that India’s GCCs run in production.
Managed services belong to the guild of the engine underneath them, because a replica lagging on Aurora and one lagging on a self-managed cluster share a root cause more often than they share a dashboard. Most members join two or three guilds.
The ten guilds
| Guild | Engines and services | What the guild works on |
|---|---|---|
| PostgreSQL | PostgreSQL, Google AlloyDB, and PostgreSQL on Amazon RDS, Aurora, Cloud SQL and Azure | Autovacuum and bloat, wraparound, logical replication, Patroni HA, PgBouncer, extensions, major-version upgrades |
| MySQL and MariaDB | MySQL, MariaDB, Amazon RDS, Amazon Aurora, Google Cloud SQL | InnoDB tuning, Group Replication and Galera, ProxySQL, online schema change, 8.0-to-8.4 moves, MySQL and MariaDB divergence |
| SQL Server | Microsoft SQL Server, Azure SQL | Always On availability groups, Query Store and plan regressions, index strategy, licensing-aware sizing, Azure SQL migrations |
| Oracle, Db2 and SAP HANA | Oracle, IBM Db2 (LUW and z/OS), SAP HANA | Patching cadence, Data Guard and HADR, HANA system replication, licence boundaries, modernisation and offload |
| Distributed SQL | YugabyteDB, CockroachDB, Citus | Sharding and data placement, multi-region latency, rebalancing, and when distributed SQL is the wrong answer |
| NoSQL | MongoDB, Apache Cassandra, Amazon DynamoDB | Shard-key and partition-key design, compaction, capacity modes and hot partitions, consistency trade-offs |
| Redis and Valkey | Redis, Valkey | Memory and eviction, persistence trade-offs, cluster topology, the Redis-or-Valkey decision after the licence change |
| Real-time analytics | ClickHouse, Vertica, Trino | MergeTree design, ingestion at scale, projections and materialised views, federated queries, Keeper and DR |
| Cloud warehouse and lakehouse | Amazon Redshift, Google BigQuery, Snowflake, Databricks | Spend against data growth, workload isolation, commit renewals, open table formats, warehouse-to-lake moves |
| Vector | Milvus, pgvector and vector features in the engines above | Index choice and recall, memory sizing, freshness, the AI data foundations that model programmes wait on |
Five practices across every guild
Some problems are not about an engine. Five practice groups meet quarterly and draw members from every guild.
Reliability
HA, DR drills that actually restore, on-call design, SLOs and error budgets.
Performance
Plans, waits, indexing, partitioning, connection pooling and capacity.
Cost
Cloud database FinOps, reserved capacity, licence and commit strategy.
Security and compliance
DPDP, RBAC, audit logging, masking and data residency.
Migration
Between engines, versions and clouds, with the rollback path written first.
How a guild runs
- Monthly guild session. Sixty minutes, online. One member walks through a real incident, migration or design: twenty minutes of story, thirty of questions, ten of what the guild would do. Engine and version named, customer never.
- City chapters. Bengaluru, Hyderabad, Pune and Chennai, an evening each quarter.
- The peer bench. A question goes to three members who run that engine at comparable scale. Answers within 48 hours.
- The reading room. Anonymised summaries, post-mortems, runbooks and reference designs, searchable by engine.
- Special Interest Groups. Ten smaller working groups, one per platform plus one for cloud DBaaS, where members who run that platform in production write the runbooks and drills. See the SIGs.
- Two stewards per guild. Elected by guild members for a year. They run sessions, read applications and route questions. A steward may not hold a sales or pre-sales role anywhere.
Missing your engine?
Tell the secretariat. A new guild opens when twenty members ask for it and two agree to steward it. Engines run inside another guild’s family, such as a managed fork or a cloud variant, join that guild first.
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.