Google Cloud: PostgreSQL community contribution updates

by Dilip Kumar, Cloud SQL for PostgreSQL & Matt Cornillon, Sales EMEA

Google Cloud is deeply committed to the long-term success of the PostgreSQL ecosystem. Our involvement goes beyond providing PostgreSQL managed services; it's also about active participation in the open source communities through technical contributions, leadership in conference committees, and sharing architectural insights that benefit all users. Following is a recap of recent events Google Cloud participated in.

PGConf.dev 2026

Serving as a vital developer-centric hub, PGConf.dev provides a unique opportunity for collaboration with the full assembly of senior PostgreSQL committers. This gathering is essential for aligning technical efforts and shaping the future project roadmap.

Key Highlights

• Participation focused on strategic coordination with PostgreSQL committers regarding logical replication development, and a consultation on global index architecture.
• High community interest confirms the Global Index feature solves a vital architectural requirement for enterprises.
• Established community consensus to pursue a deparsing-based architectural approach for DDL replication.

Google Cloud Sessions

Dilip Kumar, a PostgreSQL contributor from Google Cloud, presenting "Experimenting with a Global Index in PostgreSQL" at pgconf.dev 2026 in Vancouver. He is speaking at a podium next to a presentation slide detailing the Global Index storage architecture and PartitionIdentifier management.

Session Title	Session Type	Speakers/Led by
Experimenting with a Global Index in PostgreSQL: Design, Implementation, and Challenges	Technical Talk	Dilip Kumar
Unconference: Global Indexes	Unconference Session	Dilip Kumar
Unconference: Logical Replication: Warts and Missing Pieces	Unconference Session	Hannu Krosing

PGConf India 2026

Key Highlights

• The three-day conference was divided into a training day followed by two days of sessions. More than 580 participants attended the conference over three days.
• The conference sessions included a mix of keynotes, breakout technical sessions, sponsor sessions, and booth interactions.

Google Cloud Sessions

Session Title	Session Type	Speakers
Database And GenAI	Keynote	Paresh Rathod
Experimenting with a Global Index in PostgreSQL	Technical Talk	Dilip Kumar
GCP - Best home to run PostgreSQL	Sponsor Session	Trusar Borse, Abhijeet Rajkur
Beyond shared_buffers: On-Demand Memory PostgreSQL	Technical Talk	Rajeev Rastogi, Vaibhav Popat
Where is my Memory	Technical Talk	Pushkar Kalidkar
Agentic AI Applications with GCP Databases	Keynote	Abhijeet Rajkur, Rishi Kapoor, Saurabh Gupta

PGDay Paris & PGDay France 2026

France hosts two distinct flagship PostgreSQL events, and Google Cloud is deeply embedded in both as both organizers and technical contributors. While PGDay Paris serves as an international, English-language hub for the European community, PGDay France is a community-driven, traveling event that focuses on the francophone ecosystem, taking place in Toulouse for 2026.

Key Highlights

• Matt Cornillon served on the organization committee for PGDay France, while Yves Colin contributed as a member of the program committee.

Google Cloud Sessions

Session Title	Session Type	Speakers
Creating a "Dungeon Master" with Postgres and MCP	Technical Talk	Matt Cornillon
Create your first AI agent with PostgreSQL	Workshop	Matt Cornillon, Yves Colin

PGDay FOSDEM 2026

FOSDEM PGDay is a prominent open source gathering that brings together developers from across the globe to discuss the latest PostgreSQL advancements. It serves as an essential platform for exploring emerging paradigms in database development.

Key Highlights

• Exploration of how AI-assisted workflows are redefining development beyond standard autocomplete for SQL queries.

Google Cloud Sessions

Session Title	Session Type	Speakers
Vibe-coding with Postgres: really?	Technical Talk	Matt Cornillon

PGConf Belgium 2026

PGConf Belgium 2026 took place at the UCLL Campus Proximus in Haasrode, Belgium, serving as an outstanding learning and networking platform for the local PostgreSQL community and students.

Key Highlights

• The session was selected by faculty as supportive material for a database exam following deep student engagement.

Google Cloud Sessions

Session Title	Session Type	Speakers
Creating a "Dungeon Master" with Postgres and MCP	Technical Talk	Matt Cornillon

Nordic PG Day 2026

Nordic PG Day is the largest PostgreSQL event in the Scandinavian countries. The 2026 edition took place in Helsinki, gathering more than 130 PostgreSQL enthusiasts for a day of deep dives.

Key Highlights

• Google joined as an official Partner-level sponsor for the first time, including a dedicated table booth.

Google Cloud Sessions

Session Title	Session Type	Speakers
Unlock AI Agents with PostgreSQL	Technical Talk	Mats Berglin, Miguel Toscano

Swiss PGDay 2026

Swiss PG Day is the annual event organized by the Swiss PostgreSQL User Group in Rapperswil, Switzerland. The ninth edition featured sessions in both English and German.

Key Highlights

• Demonstration of the physical impact of pushing millions of vectors to PostgreSQL based on a real-world use case.

Google Cloud Sessions

Session Title	Session Type	Speakers
Surviving pgvector in production: a reality check	Technical Talk	Miguel Toscano

Postgres Conference: 2026 San Jose

Since its inception in 2007, the Postgres Conference has served as a cornerstone for advancement, fostering a rich environment for learning and professional networking.

Key Highlights

• Google proudly served as a sponsor for the event.
• Adapting PostgreSQL for the artificial intelligence era demands a transformation in operational approaches. With the rise of natural language tools and vibe coding speeding up development, Agentic AI places advanced demands on production databases. In his presentation, Vikas examines how Google Cloud managed services have evolved to handle these workloads, providing architectural strategies and best practices for contemporary AI deployment.

Google Cloud Sessions

Session Title	Session Type	Speakers
Postgres and AI - Stronger Together!	Technical Talk	Vikas Arora

Community Leadership and Committees

Googlers play a vital role in shaping the direction of the most prestigious PostgreSQL developer events. Our leadership in these committees helps ensure that enterprise-grade requirements—such as those needed for large-scale migrations—are part of the global conversation.

• PGConf.dev 2026: Dilip Kumar served on the Program Committee.
• PGConf India 2026: Dilip Kumar was a member of the Paper Selection Committee.
• PGDay France: Matt Cornillon was a member of the organization committee and Yves Colin served as a member of the Program Committee.

Looking Forward

Our commitment remains firm: to turn feedback from these global events into code, reviews, and active community partnerships. We thank the wider PostgreSQL community and the project's committers for their continued collaboration in making PostgreSQL better for everyone.

Acknowledgement

We extend our heartfelt appreciation to our open source community contributors for their outstanding dedication and active participation in making PostgreSQL conferences a great success.

Abhijeet Rajurkar, Darshan Nagarajappa, Dilip Kumar, Hannu Krosing, Mats Berglin, Matt Cornillon, Michael Bautin, Miguel Toscano, Niranjan Shivprasad, Paresh Rathod, Rajeev Rastogi, Vaibhav Popat, Vikas Arora, and Yves Colin

Furthermore, we are deeply grateful to the broader PostgreSQL open-source communities, especially the dedicated conference organizers, committee members, and all supporting sponsors.

Community feedback: How can corporations improve support for open source maintainers?

by Sophia Vargas, Google Open Source

We know that AI is actively transforming the sustainability and socio-technical dynamics of OSS communities. Google Open Source is committed to partnering with open source communities and ecosystems to learn together how we should update our own models for engagement and support.

During an open meetup for GitHub Maintainer Month, I led a session to gather community feedback on how corporations can more effectively support open source maintainers.

Paying maintainers takes creativity

Many maintainers would appreciate consistent financial support. However, facilitating payments to individuals without established contractual relationships remains a complex challenge, particularly across diverse international jurisdictions. Fiscal hosts and programs such as Open Collective, GitHub Sponsors, and the LFX Mentorship Program can simplify components of this process, but they do not resolve the underlying issues of funding sustainability and predictability. While initiatives like the Open Source Endowment are working toward long-term funding sustainability, individual maintainers also had a few ideas:

• Pay per meaningful contribution vs gameable metrics: Avoid payment models based on easily manipulated units like pull request counts or review volume. A proposed alternative is ‘pay per report,' encouraging maintainers to document their achievements and upcoming roadmaps.
• Commitment-based purchasing: Corporate policies might make procurement simpler (or more complex) than sponsorships, so maintainers could benefit from offering structured support services alongside traditional sponsorship opportunities.
• Fund conference attendance: In-person networking can be a boon for solo maintainers but it's often cost-prohibitive. For some corporations, travel sponsorship may be a simpler alternative to direct payments.

Challenge for Corporations and Fiscal Hosts: How can we assist maintainers in understanding any and all prerequisites and documentation necessary to participate in monetary programs?

Advice from Maintainers: Consult a tax professional to understand the implications of various funding methods.

Manage and respect expectations

Beyond financial support, our discussion returned to the importance of respect and etiquette. Particularly, how can we manage expectations between heterogeneous creators, contributors and users - are maintainers clearly communicating their preferences, and are corporations actively respecting them? Some suggestions include:

• Adherence to community norms: Maintainers should share their preferred communication channels, while contributors - both human and agentic - must ensure they review and follow them.
• Consistency with documentation: Discrepancies between documented procedures and actual practices create friction for all participants. This standard should be upheld by both individual maintainers and corporate-managed projects.
• Clarity of intent: Many maintainers would like to understand the motivation behind a contribution and reserve the right to ask questions.

To improve specific program experiences, maintainers suggested:

• Consistent communication: Recipients of funding programs expect clearly communicated expectations regarding the timing and amount of disbursements.
• Transparency and discoverability: Maintainers would appreciate easily discoverable records that track program participation, active agreements, and verify the status of Contributor License Agreements (CLAs).

Let's keep learning as a community

While we cannot make any promises, we want to continue to learn and challenge ourselves to consider novel ways to support OSS communities and maintainers. As a member of our community, we value your opinion. We've created a Google form to collect any thoughts you might have, as well as gauge interest in another open meeting. We plan to share any and all learnings back with the community.

Documenting the manual: how curiosity and robotic arms led to a career in open source

by Daryl Ducharme, Google Open Source

When you think of "innovation" in open source, your mind probably jumps to the latest AI model or a revolutionary new framework. You might not immediately think of manual pages. Even Alejandro "Alex" Colomar, who spends his days maintaining Linux Kernel documentation, jokingly admits that some might find the work "boring" because it focuses on fixing existing issues and documenting new features rather than flashy inventions.

But as any developer knows, the most powerful code is only as good as the documentation behind it. At Google, we believe that investing in the success of projects we don't own is a core part of being a good open source citizen. That is why we are proud to sponsor Alejandro's work on the Linux Kernel man-pages project—supporting the critical infrastructure that many of our own systems rely on every day.

Documentation is the gift you give to your future self and your whole community.

The precision of a robot

Alejandro's journey into the world of essential documentation started at university. He was working with robotic arms that used a proprietary scripting language. Wanting more control, he decided to write a C library to communicate with the robots over the network by sniffing packets with Wireshark. It worked, but it was slow—he had to wait seconds between commands to ensure the robot had finished moving.

To make the movements smooth, he needed to understand the messages the robot was sending back in real-time. This required high-precision timing. He found SO_TIMESTAMP, which provided microsecond precision, but he noticed a macro called SO_TIMESTAMPNS in the header files that promised nanosecond resolution. The problem? It wasn't documented in the manual page.

The first patch

After figuring out how to use the undocumented feature by looking at the kernel source code, Alejandro decided to ensure the next person wouldn't have to struggle. He cloned the man-pages repository, wrote a new paragraph based on existing features, and figured out how to send a plain-text patch via email.

"As it was my first patch, I was a bit intimidated by the procedure," Alejandro recalls. That intimidation led to a commit message he is still proud of today: roughly 120 lines of explanation for just 25 lines of new documentation. He wanted to prove that he had done his homework. The welcoming response from the maintainer encouraged him to keep going, leading to more patches and, eventually, a career-long dedication to clarity in open source communities.

Sustaining the commons

Google understands that open source is a "small community built on trust." By supporting maintainers like Alejandro, we help ensure that critical infrastructure—like the documentation that powers the Linux ecosystem—remains accurate and accessible for everyone. We believe that using open source comes with a responsibility to contribute and sustain it, which is why we partner with developers to maintain and grow critical projects.

Alejandro's work doesn't just help himself; it helps thousands of other programmers who rely on correct documentation to build the next generation of technology. As he puts it: "I couldn't program without correct documentation, so whenever I find an issue in documentation, I try to fix it."

A garden that needs tending

We often say that a community is a garden, not a building—it requires constant tending, not just initial construction. By sponsoring Alejandro, we are helping to tend that garden, ensuring the "manual" remains a living, breathing resource for the global developer ecosystem. Whether it is fixing a typo or documenting a high-precision networking macro, every contribution makes the "eyes" on the code that much sharper.

In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35

by Duncan Campbell & Giuseppe Tinti Tomio, Kubernetes

Operational efficiency and system resilience are critical when running scaled platforms. Yet, in Kubernetes, recovering from software crashes remains a headache because you couldn't trigger a clean restart of a Pod's containers without recreating the entire Pod object, leading to some amount of resource waste.
To address this, Restart All Containers on Container Exits graduated to beta and is enabled by default in Kubernetes v1.36. Developed in close collaboration with the CNCF community, this capability represents Google's commitment to investing in the success of foundation-led open source projects. By sharing best practices from running large distributed systems internally, we are helping build a more resilient and efficient ecosystem. Letting containers restart while keeping the Pod's runtime identity provides a built-in way to perform in-place Pod recovery, boosting application reliability and saving resource costs.

The Problem: The High Cost of Pod Re-creation

Historically, Kubernetes managed failures using pod level restart policies. While sufficient for simple services, modern multi-container Pods often have complex dependencies. When a failure requires a full environment reset, your only option was deleting and recreating the entire Pod.
This introduces massive control plane churn, causing latency and pressure on the etcd backend during large failures:

• Initialization Dependencies: If a main container corrupts a local environment, for example, single-use secrets that must be re-requested, restarting just that container is insufficient; the setup must run again.
• Watcher Interoperability: If a watcher sidecar detects a fatal error, it must trigger a full recreate of the entire pod and its infrastructure, including the sandbox.
• Stale States: If a database sidecar proxy restarts, the main application can get stuck attempting to use stale, broken connections.
• Resource Race Conditions: When a large job finds a proper set of nodes, recreating Pods can lead to other pending Pods taking over those resources. In-place restarts eliminate this race condition risk.

Previously, resolving these failures required destroying the entire Pod. For large batch or AI/ML workloads, where thousands of Pods might fail simultaneously, this can lead to "Thundering Herd" scheduling requests, delaying recovery and wasting expensive GPU/TPU compute time.

Introducing In-Place Restarts: The RestartAllContainers Action

Kubernetes v1.35 introduces the RestartAllContainers action, enabled by the RestartAllContainersOnContainerExits feature gate, which graduated to beta in 1.36 alongside its dependencies ContainerRestartRules and NodeDeclaredFeatures. This lets a container's exit behavior trigger a fast, in-place restart of the entire Pod on its existing node.
The Kubelet halts all containers while keeping the Pod sandbox intact, preserving critical infrastructure:

• Network Identity: Keeps the same IP, network namespace, and UID, completely bypassing IP reassignment.
• Hardware and Devices: Keeps GPUs/TPUs bound, eliminating scheduling and re-allocation delays.
• Storage Mounts: Volumes, including emptyDir and PVCs, remain fully mounted; their content is not cleared during restarts.

Once terminated, the Kubelet re-runs init containers (including sidecars, which are part of the init sequence) in order, guaranteeing a clean setup in a known-good environment.

A Native Pod Specification Example

You can implement this under the container's restartPolicyRules field. Here is a quick example of how a watcher sidecar can trigger an in-place restart of the entire Pod by exiting with code 88:
YAML
Note: Image names and paths in the YAML below are for illustrative purposes.

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
    - name: setup-environment
      image: registry.k8s.io/ml-tools/setup-worker:v1.0
    - name: watcher-sidecar
      image: registry.k8s.io/ml-tools/watcher:v1.0
      restartPolicy: Always
      restartPolicyRules:
        - action: RestartAllContainers
          exitCodes:
            operator: In
            values: [88]
  containers:
    - name: main-application
      image: registry.k8s.io/ml-tools/training-app:v1.0

The Operational Impact of In-Place Restarts

For organizations running distributed workloads, RestartAllContainers provides serious operational advantages:

• No Control Plane Overhead: By preserving identity, clusters avoid scheduling latency and DNS propagation. This was a key factor for JobSet using this feature to reduce recovery from minutes to seconds.
• Node Locality Preservation: Since the Pod stays anchored to the same node, restarted containers can instantly access local, warm storage caches.
• Maximized Hardware Efficiency: In distributed AI training, losing a single node halts the entire job. Keeping accelerators like GPUs/TPUs bound lets workloads resume training significantly faster, directly reducing compute costs.

Observability and SRE Best Practices

To support monitoring, Kubernetes v1.35 introduces the AllContainersRestarting Pod condition. Set to True during restarts, it alerts SREs and autoscalers, preventing false-positive alerts, while container restart counts increment to let Prometheus easily track recovery events.
To use in-place restarts successfully, shift your mental model to "persistent sandboxes" and follow three best practices:

1. Ensure Reentrancy: Kubelet only guarantees "at least once" execution for init containers. Reentrancy is now a standard requirement, so your code must be fully idempotent.
2. Plan for Termination Handling: Graceful termination (preStop hooks) is not supported for in-place restarts. SIGKILL is almost immediate, so applications must handle sudden exits gracefully.
3. Prepare External Tooling: CD and observability tools should expect re-running init containers without interpreting them as new deployments.

What's Next?

This beta capability is a major step toward fluid workload management and serves as a building block for advanced community features like JobSet in-place restarts (KEP-467).
Our work on KEP-5532 reflects our commitment to transparent open source governance. Developed collaboratively within SIG Node, this feature shows how we hold ourselves to high citizenship standards; making our design, goals, and intentions transparent while building shared best practices that benefit everyone. We encourage you to experiment with Kubernetes v1.35 and share your feedback with the community!

Learn More

• Read the Kubernetes Pod Lifecycle Documentation.
• Explore KEP-5532: Restart All Containers on Container Exits.
• Review theKubernetes v1.35: Restart All Containers Blog Post.
• Join the SIG Node Community on Slack (#sig-node).

Open rails for agentic commerce at Open Source Summit North America 2026

by Anurag Sinha, Universal Commerce Protocol (UCP)

At Open Source Summit North America 2026, I shared why agentic commerce needs open rails.

As AI agents become more capable, the shopping journey is shifting from "show me" to "help me." Instead of browsing, comparing, clicking, and checking out step by step, people can increasingly ask an agent to help them decide what to buy and, in some cases, complete the purchase. Industry forecasts suggest agentic shopping could account for roughly 10% to 25% of U.S. e-commerce by 2030 (Bain), which points to a meaningful shift in how digital commerce will work. Watch the full keynote here.

Why shared rules matter

That shift also exposes a challenge. Commerce is still highly fragmented. Different businesses, payment providers, and platforms operate with their own rules, workflows, and business logic. Every new surface adds more integration work. Every bespoke connection creates more complexity. And that fragmentation makes it harder for AI systems to understand and perform commerce actions consistently across businesses. A shared language lowers that barrier for everyone.

A common language for agentic commerce

That is the problem Universal Commerce Protocol (UCP) is designed to solve.

We launched the Universal Commerce Protocol, or UCP, with industry leaders to establish an open standard for agentic commerce, built to work across the shopping journey. UCP creates a common language for agents and systems to operate together across consumer surfaces, businesses, and payment providers, so the ecosystem does not need a different bespoke integration for every new agent or platform.

Just as importantly, UCP is designed for the real world. Every business has its own way of selling. Checkout, fulfillment, loyalty, policy logic, shipping, and post-purchase flows can vary widely between a local shop, a marketplace, and a large retailer. UCP is built to support that reality.

A layered architecture for a shared commerce language

UCP uses a layered model to create a reusable shared language for commerce. Services organize domains like shopping and common. Capabilities define core actions such as checkout, catalog, cart, orders, and shared functions like identity linking. Extensions keep those capabilities configurable, so features like fulfillment can be modeled once and reused across multiple flows instead of being hardwired each time. At the transport layer, UCP stays agnostic, supporting bindings like REST, Model Context Protocol, and Agent2Agent.

Together with capability discovery and payment handling, these layers help consumer platforms, agents, and businesses interoperate more consistently over time. They also let different participants advertise what they support, compose new behaviors, and communicate over the transport that works best for them.

Built in the open

A standard for everyone should be shaped by everyone. Because UCP is open, merchants, developers, and community contributors can pressure-test real-world gaps, propose new capabilities and extensions, and help make sure the protocol reflects more than the needs of the largest players. That kind of participation is what keeps an ecosystem moving.

Since launch, UCP has continued to evolve through new capabilities, an expanded Tech Council, and new consumer experiences built on top of the protocol. That momentum matters because standards only work when the ecosystem uses them.

Watch the full keynote

Agentic commerce is still evolving, and UCP is a foundational building block to support what's next in this new era.

If you want the full architecture walkthrough and the complete story from Open Source Summit North America, watch the session here. And if you want to go deeper, you can explore the UCP documentation, join the community conversation, and contribute to the public repository.