2026 年 6 月下旬，PostgreSQL 社区在欧洲多地连续发生了几件值得记录的事：伦敦、里尔、法兰克福、荷兰用户组相继举办 Meetup，PGDay UK 2026 的项目委员会敲定日程，Swiss PGDay 2026 也在 6 月 25–26 日举行。单看每场活动，它们像是普通的社区聚会；连起来看，则能看到一个成熟开源数据库社区如何靠本地组织者、讲者和议程委员会持续运转。
这一周并不只是“几场 Meetup”
这份记录里最明显的线索，是 PostgreSQL 社区的活动密度。
6 月 23 日，London PostgreSQL Meetup Group 举办活动，由 Valeria Kaplan、Chris Ellis、Alastair Turner、Michael Christofides 组织，Andreas Karlsson、Alastair Turner、Valeria Kaplan 担任讲者。同一天，PostgreSQL Lille Meetup 也举行了活动，Stefan Fercot 和 Yoann La Cancellera 既是组织者，也参与了演讲。
6 月 24 日，Postgres User Group Frankfurt am Main 聚会，Marc Linster 发表演讲，活动由 Valeria Kaplan、Dirk Aumueller、Diego Calvo de Nó、Ilya Kosmodemiansky 组织。
6 月 25 日，PostgreSQL User Group NL 举办 Summer Edition，Gerard Zuidweg 和 Feike Steenbergen 负责组织，Matthias van der Meent、Bart Orbons、Jan Karremans 担任讲者。
同一时间，PGDay UK 2026 的 Program Committee 也完成了日程敲定工作，参与者包括 Celeste Horgan、Greg Clough、Sastry Karamcheti、Alastair Turner。Swiss PGDay 2026 则在 6 月 25–26 日举办，组织者、选题团队、正式讲者和 lightning talk 讲者名单都很长，说明它已经不是临时聚会，而是有完整会议机制的区域性 PostgreSQL 活动。
成熟社区靠角色分工，而不是靠“热情”硬撑
这周活动里反复出现几个角色：组织者、讲者、项目委员会、选题团队、lightning talk 讲者。它们看似是名单分类，实际对应着社区运行的不同职责。
组织者负责把场地、时间、宣传、报名和现场流程串起来。讲者负责把经验、案例或技术细节带到台前。项目委员会和选题团队则承担更难的工作：让议程有节奏、有覆盖面，也避免活动变成少数主题的重复播放。
值得注意的是，一些名字出现在多个场景中。例如 Valeria Kaplan 既参与 London PostgreSQL Meetup Group 的组织和演讲，也参与 Frankfurt 用户组活动组织；Alastair Turner 既是伦敦活动讲者和组织者之一，也参与 PGDay UK 2026 日程敲定。这种跨活动参与，是技术社区保持连续性的关键：经验不会只停留在某个城市或某个会议里。
可以这样实践：用 PostgreSQL 管理社区活动数据
如果你在维护本地用户组，最容易失控的不是技术内容，而是活动、讲者、角色和日期的追踪。下面是一个可以直接在 PostgreSQL 里运行的最小模型，用来记录类似这一周的社区活动。
运行前修改数据库连接方式即可，例如使用本地 psql：
createdb pg_community
psql pg_community
然后执行以下 SQL：
CREATE TABLE community_event (
id bigserial PRIMARY KEY,
name text NOT NULL,
city_or_region text NOT NULL,
starts_on date NOT NULL,
ends_on date NOT NULL,
event_type text NOT NULL CHECK (event_type IN ('meetup', 'conference', 'program_committee'))
);
CREATE TABLE participant (
id bigserial PRIMARY KEY,
full_name text NOT NULL UNIQUE
);
CREATE TABLE event_role (
event_id bigint REFERENCES community_event(id) ON DELETE CASCADE,
participant_id bigint REFERENCES participant(id) ON DELETE CASCADE,
role text NOT NULL CHECK (role IN ('organizer', 'speaker', 'program_committee', 'selection_team', 'lightning_speaker')),
PRIMARY KEY (event_id, participant_id, role)
);
INSERT INTO community_event (name, city_or_region, starts_on, ends_on, event_type) VALUES
('London PostgreSQL Meetup Group', 'London', '2026-06-23', '2026-06-23', 'meetup'),
('Meetup PostgreSQL Lille', 'Lille', '2026-06-23', '2026-06-23', 'meetup'),
('Postgres User Group Frankfurt am Main', 'Frankfurt am Main', '2026-06-24', '2026-06-24', 'meetup'),
('PostgreSQL User Group NL Summer Edition', 'Netherlands', '2026-06-25', '2026-06-25', 'meetup'),
('PGDay UK 2026 schedule finalization', 'United Kingdom', '2026-06-25', '2026-06-25', 'program_committee'),
('Swiss PGDay 2026', 'Switzerland', '2026-06-25', '2026-06-26', 'conference');
INSERT INTO participant (full_name) VALUES
('Valeria Kaplan'),
('Alastair Turner'),
('Stefan Fercot'),
('Yoann La Cancellera'),
('Marc Linster'),
('Gerard Zuidweg'),
('Feike Steenbergen'),
('Matthias van der Meent'),
('Bart Orbons'),
('Jan Karremans'),
('Celeste Horgan'),
('Greg Clough'),
('Sastry Karamcheti'),
('Marion Baumgartner'),
('Tobias Bussmann'),
('Andreas Geppert'),
('Stefan Keller'),
('Daniel Westermann')
ON CONFLICT (full_name) DO NOTHING;
再插入几个角色关系，观察谁跨活动参与：
INSERT INTO event_role (event_id, participant_id, role)
SELECT e.id, p.id, 'organizer'
FROM community_event e, participant p
WHERE e.name = 'London PostgreSQL Meetup Group'
AND p.full_name IN ('Valeria Kaplan', 'Alastair Turner');
INSERT INTO event_role (event_id, participant_id, role)
SELECT e.id, p.id, 'speaker'
FROM community_event e, participant p
WHERE e.name = 'London PostgreSQL Meetup Group'
AND p.full_name IN ('Valeria Kaplan', 'Alastair Turner');
INSERT INTO event_role (event_id, participant_id, role)
SELECT e.id, p.id, 'program_committee'
FROM community_event e, participant p
WHERE e.name = 'PGDay UK 2026 schedule finalization'
AND p.full_name IN ('Celeste Horgan', 'Greg Clough', 'Sastry Karamcheti', 'Alastair Turner');
INSERT INTO event_role (event_id, participant_id, role)
SELECT e.id, p.id, 'organizer'
FROM community_event e, participant p
WHERE e.name = 'Swiss PGDay 2026'
AND p.full_name IN ('Marion Baumgartner', 'Tobias Bussmann', 'Andreas Geppert', 'Stefan Keller', 'Daniel Westermann');
SELECT
p.full_name,
count(DISTINCT e.id) AS event_count,
string_agg(DISTINCT er.role, ', ' ORDER BY er.role) AS roles
FROM participant p
JOIN event_role er ON er.participant_id = p.id
JOIN community_event e ON e.id = er.event_id
GROUP BY p.full_name
HAVING count(DISTINCT e.id) > 1
ORDER BY event_count DESC, p.full_name;
这个查询不只是“统计名字”。它能帮助社区维护者发现哪些人承担了多重角色，哪些活动过度依赖少数贡献者，以及下一次是否应该主动培养新的主持人、讲者或评审成员。
对开发者有什么意义
对 PostgreSQL 使用者来说，社区活动不是新闻花絮。很多数据库实践并不会第一时间变成正式文档：迁移经验、性能排查套路、扩展使用边界、版本升级踩坑，往往先出现在 Meetup 或 PGDay 的演讲里。
如果你所在团队重度使用 PostgreSQL，可以把社区活动当成技术雷达的一部分：
- 关注本地用户组，优先听和你业务规模接近的案例。
- 记录讲者和主题，而不只是收藏幻灯片链接。
- 鼓励团队成员做 lightning talk，把内部经验压缩成可讨论的问题。
- 对大型会议议程做复盘，识别未来半年值得验证的数据库方向。
- 不要只消费内容，也尝试承担一次组织、翻译、记录或主持工作。
采用建议：把社区参与变成工程习惯
这周的 PostgreSQL 活动说明，一个健康技术生态不是靠单点爆发，而是靠多城市、多角色、多层级会议持续积累。对个人开发者，最小行动可以是参加一次本地 Meetup；对团队，最小行动可以是建立一个内部 PostgreSQL watchlist，每月整理社区演讲、版本动态和实践问题。
真正有价值的社区参与，不一定是立刻站上大会舞台。更现实的起点是：记录一次活动、复现一个演示、向讲者提一个具体问题，或者把自己踩过的 PostgreSQL 坑整理成 10 分钟分享。长期看，这些小动作会变成组织的数据库判断力。