GSoC 2025

This page is for collecting ideas for Google Summer of Code 2025 projects. This page is for IDEAS ONLY.
 IF YOU ARE A CONTRIBUTOR: there is a top-level GSoC page for PostgreSQL here: PostgreSQL General GSoC Page - please read this first before proceeding to contact mentors! Contribution guidelines, channels and communication methods are in this page too. PLEASE make sure you have read everything thoroughly.
If you are a mentor and would like to participate, feel free to edit this page and put your name below.
Mentors mailing list for proposals: gsoc2025-mentors@lists.postgresql.org
== Proposals ==
Proposals are still work in progress. If you are a mentor and would like to participate, feel free to edit this page and put your name below. 
== Admins ==
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
* Pavlo Golub <pavlo (dot) golub (at) gmail (dot) com>
== Mentors ==
The following individuals have been listed as possible mentors on the below projects, and/or offered to be mentors for student-proposed projects:
* Pavlo Golub
* Jesper Pedersen
* David Wheeler
* Mark Wong
* Akshat Jaimini
* Saurav Pal
* Shahryar Soltanpour
* Haoran Zhang
* Luca Ferrari
* Rajiv Harlalka
* Andreas Scherbaum
== Upgrade pgwatch Grafana dashboards to v11 ==
=== Project Description ===
The project focuses on updating the current pgwatch Grafana dashboards to ensure full compatibility with Grafana version 11. While a portion of the dashboards have already been automatically migrated to the new Grafana v11 model, they still require polishing and manual rework to fully leverage the new features and to address any discrepancies caused by differences between Grafana v10 and v11. Key differences include the removal of AngularJS-based components, modifications in panel JSON structure, and enhanced transformation capabilities. The mentee is welcome to improve the overall dashboarding experience by integrating new features, updating deprecated elements, and enhancing panels as needed. 
=== Skills needed ===
* Proficiency in Grafana dashboard configuration and JSON model modifications
* Familiarity with the differences between Grafana v10 and v11
* Experience with Docker and Linux environments
* Basic understanding of web development concepts (HTML, CSS, JavaScript)
* PostgreSQL
=== Difficulty level ===
Moderate
=== Project size ===
Medium (~175 hours)
=== Mentors ===
* Pavlo Golub
* Akshat Jaimini
* Rajiv Harlalka
=== Expected outcomes ===
* A refined set of Grafana dashboards for pgwatch that are fully compatible with Grafana v11
* Updated and polished JSON definitions that correctly incorporate new v11 features (such as improved visualizations, transformation options, and updated panel configurations)
* Enhanced dashboards and panels that integrate new features, account for deprecated features, and improve the overall user experience
* Documentation outlining the migration process with guidelines for future dashboard updates
=== References ===
* pgwatch
* Breaking changes in Grafana v11.0
* Removal of AngularJS support in Grafana: what you need to know
* Angular support deprecation
* Custom v10 dashboards by postgres.ai (example of customization)
== Enhancements to pgwatch v3 RPC integration ==
=== Project Description ===
In GSoC 2024, we integrated Remote Procedure Calls within pgwatch v3 to provide a functionality called Remote Sinks. In 2025 we would like to enhance this implementation by adding more features and utilizing the full capabilities of Remote Procedure Calls.
=== Skills needed ===
* Go
* PostgreSQL
=== Difficulty level ===
Easy
=== Project size ===
Medium (175 hours)
Can be modified according to proposed solution
=== Mentors ===
* Akshat Jaimini
* Pavlo Golub
* Andreas Scherbaum
=== Expected outcomes ===
* Provides an authentication protocol for the current RPC implementation
* Optimized architecture
This is not a strict & exhaustive list and we encourage contributors to provide their own creative input as well
=== References ===
* pgwatch v3: 
* Remote Sinks implementation for pgwatch: 
== ABI Compliance Checker ==
=== Project Description ===
Develop and deploy an "ABI Compliance Checker", to be integrated into the PostgreSQL development process similar to coverage.postgresql.org. The checker should run on every commit to the project and produce an ABI compliance report, and trigger an alert when an ABI has changed in an incompatible way. See this thread for an example of such a report, and some details on how it was implemented. Use it as starting point for building the tool.
Once the tool reliably produces reports, work with the infrastructure team to get it added to the development pipeline and to publicly publish its reports.
=== Background ===
PostgreSQL recently added Server API and ABI Stability Guidance to help extension authors to understand how and when the server API and ABI are and are not likely to change. In practice, the guidance is that the API and ABI should maintain compatibility between minor releases (e.g., 17.0 to 17.1), but not major releases. This has long been the implicit guidance, but now it is explicit, and due to be included in the PostgreSQL 18 docs.
Today the committers adhere to this policy purely through the review process, which means once in a while an incompatible change will be included in a minor release. Such changes have been extremely rare, but this past fall an ABI change was unexpectedly shipped in PostgreSQL 17.1. It was quickly reversed in PostgreSQL 17.2, but highlights the need for some process to catch such changes before they're released.
This project will help reduce the change of such an incident again by automatically checking for ABI changes. This will improve the adherence to the guidance, perhaps allow it to be upgraded to a reliability _policy_, and give extension developers and package maintainers assurance about the reliability of extension builds on PostgreSQL minor releases.
=== Skills needed ===
* C Programming
* Command-line tooling
* HTML & CSS
* Service deployment
* Automation
=== Difficulty level ===
Medium
=== Project size ===
Medium (175 hours)
=== Mentors ===
* David Wheeler
* Pavlo Golub
=== Expected outcomes ===
* Working implementation of a subdomain of postgresql.org or as part of the build farm featuring ABI compatibility reports for every commit pushed to a back branch of PostgreSQL
* Notifications of failures sent via email to the committers
* Git repository for the project for ongoing maintenance
* Integration into the PostgreSQL infrastructure build and deploy processes
=== References ===
* abi-dumper, a potential tool
* PostgreSQL Build Farm
* Build Farm Server Code
* pgsql-hackers discussion of an example of a report and the need for a project like this
* Server API and ABI Stability Guidance
== pg_top data internal data structure refactor ==
=== Project Description ===
pg_top is a terminal tool to monitor the top running PostgreSQL processes. This project is to port and use libbsd's red-black tree data structure.
pg_top doesn't need all of what libbsd has to offer, so it makes more sense to just port tree.h.
If time permits, additional tasks can be added to improve pg_top. Some examples:
* Repeat the same exercise to port tree.h for pg_systat
* Incorporate pg_systat into pg_top's source tree, effectively turning pg_top into a project the provides two tools, this will be an exercise with the CMake build system
=== Background ===
pg_top currently uses libbsd's red-black tree data structure to organize process information but this library is not easily used on some platforms, like MacOS. The code base previously used home-grown linked lists, but I think it would be nice to use an existing library rather than revert the code.
=== Skills needed ===
* C Programming
=== Difficulty level ===
Medium
=== Project size ===
Medium (175 hours)
=== Mentors ===
* Mark Wong
* Rajiv Harlalka
=== Expected outcomes ===
* pg_top functions with ported tree.h code for at least Linux
=== References ===
* There is a #pg_top channel on the Postgres Slack
* pg_top git repository
* tree.h, a license compatible red-black tree implementation from OpenBSD source
* pg_top presentation
== Performance Farm: BuildBot test result data transformation ==
=== Project Description ===
Buildbot is a continuous integration framework being used to proof the next generation of the PostgreSQL Performance Farm project. This project is to extract data from BuildBot's database of test results, the PostgreSQL git repository, and the data saved on the Buildbot Worker to transform it, and load it into a new reporting database so that is it easier to query results.
The contributor is not expected to be familiar with Buildbot's database schema prior to starting, or the details of the various tests that are being run. An introduction to some of those details will be part of the start of the project.
=== Skills needed ===
* SQL
* POSIX Shell Scripting
* git
=== Difficulty level ===
Easy
=== Project size ===
Medium (175 hours)
=== Mentors ===
* Andreas Scherbaum
* Mark Wong
=== Expected outcomes ===
* Schema design of new reporting database
* A set of SQL and shell scripts that can be used in the Performance Farm project
=== References ===
* git
* PostgreSQL
* Example script building a static report for DBT-2 test results
== Performance Farm: Web user interface for navigating results ==
=== Project Description ===
Develop a front end in interface in JavaScript for navigating test data.
The Performance Farm prototype runs various tests against all supported branches of PostgreSQL, but the prototype doesn't really have a good interface.
Here is an example of a static way data is visualized for the results of a single system. The primary way test results are views are for on specific test (e.g. DBT-2), only on one system at a time (e.g. vanillaleaf), and at one specific scale. Then metrics from multiple git branches (e.g. HEAD, REL_17_STABLE, REL_16_STABLE, etc) may all be viewed at the same time, for any code change (i.e. commit) in the PostgreSQL repository.
File:Perffarm-dbt2.png
Here is an excerpt of raw data from one specific test for one specific system:
 branch,revision,scale,ctime,metric,complete_at
 REL_13_STABLE,3850fcca69b5db0694ceb5d1134699dc247f201e,100,1708386677,564578.0,1728363218
 REL_13_STABLE,9061fd23c28faebcb29bdfb262975639715975c0,100,1708719713,557362.69,1728362912
 REL_13_STABLE,43cca9de9a0adf3fb47aaa6310cc0022a78eee8a,100,1708895707,570032.0,1728362591
An ideal interface will let the user:
* select the branches to display
* adjust the date range on the fly
* mouse over any data point to see
** commit hash
** brief commit description
** url link to full commit
=== Skills needed ===
* JavaScript
=== Difficulty level ===
Medium
=== Project size ===
Long (350 hours)
=== Mentors ===
* Rajiv Harlalka
* Mark Wong
* Andreas Scherbaum
=== Expected outcomes ===
* Working implementation of a JavaScript interface
== pgexporter: Extension support ==
=== Project Description ===
pgexporter [1] is a Prometheus [5] exporter for PostgreSQL [4]. This project looks to enhance its functionality with support for PostgreSQL extensions. There needs to be a general framework such that it is easy to add extensions or use different versions. Top extensions like pg_stat_statements should be supported by the distribution.
=== Skills needed ===
* C
* PostgreSQL
=== Difficulty level ===
Medium
=== Project size ===
Long (350 hours)
=== Mentors ===
* Saurav Pal <palsaurav (dot) 2020 (at) gmail (dot) com>
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
=== Expected outcomes ===
* Top PostgreSQL extensions working out-of-the-box in pgexporter releases
=== References ===
[1] https://github.com/pgexporter/pgexporter
[2] https://github.com/pgexporter/pgexporter_ext
[3] https://pgexporter.github.io/
[4] https://www.postgresql.org/
[5] https://prometheus.io/
== pgmoneta: WAL record filtering ==
=== Project Description ===
Apply custom filtering rules to WAL records before generating new files.
Filter based on:
* Transaction type (INSERT, UPDATE, DELETE, etc.).
* Schema or table names to allow selective replication.
* Custom conditions for targeted processing.
Expand with Cross-Version WAL Streaming where these files can be streamed to other versions of PostgreSQL
based backups.
=== Skills needed ===
* C
* PostgreSQL
=== Difficulty level ===
Hard
=== Project size ===
Long (350 hours)
=== Mentors ===
* Shahryar Soltanpour <shahryar (dot) soltanpour (at) gmail (dot) com>
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
=== Expected outcomes ===
* Implement filtering mechanism that can generate PostgreSQL WAL files for different versions.
=== References ===
[1] https://github.com/pgmoneta/pgmoneta
[2] https://pgmoneta.github.io/
[3] https://www.postgresql.org/
== pgmoneta: Incremental backup for PostgreSQL 13-16 ==
=== Project Description ===
Implement functionality in pgmoneta and pgmoneta_ext such that an incremental
backup can be taken from PostgreSQL 13 to 16.
This work can build upon the work done in the incremental backup support for PostgreSQL 17
inside of pgmoneta.
=== Skills needed ===
* C
* PostgreSQL
=== Difficulty level ===
Hard
=== Project size ===
Long (350 hours)
=== Mentors ===
* Haoran Zhang <andrewzhr9911 (at) gmail (dot) com>
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
=== Expected outcomes ===
* Incremental backup working inside pgmoneta for PostgreSQL 13 - 16
=== References ===
[1] https://github.com/pgmoneta/pgmoneta
[2] https://github.com/pgmoneta/pgmoneta_ext
[3] https://pgmoneta.github.io/
[4] https://www.postgresql.org/
== pgmoneta: Clustering support ==
=== Project Description ===
Implement functionality in pgmoneta and pgmoneta_ext such that pgmoneta can operate
in a clustered way meaning f.ex. the result of a backup operation is replicated to
another pgmoneta node.
It should be possible to control which node replicates to which node(s).
=== Skills needed ===
* C
* PostgreSQL
=== Difficulty level ===
Hard
=== Project size ===
Long (350 hours)
=== Mentors ===
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
* Haoran Zhang <andrewzhr9911 (at) gmail (dot) com>
=== Expected outcomes ===
* Have backup replicate between pgmoneta nodes
=== References ===
[1] https://github.com/pgmoneta/pgmoneta
[2] https://github.com/pgmoneta/pgmoneta_ext
[3] https://pgmoneta.github.io/
[4] https://www.postgresql.org/
== pgagroal: Enhance security ==
=== Project Description ===
This project looks to enhance the security in pgagroal.
Areas could include
* Database aliases
* Better support for X.509 certificates
* Improve the vault implementation
=== Skills needed ===
* C
* PostgreSQL
=== Difficulty level ===
Medium
=== Project size ===
Long (350 hours)
=== Mentors ===
* Luca Ferrari <fluca1978 (at) gmail (dot) com>
* Jesper Pedersen <jesper (dot) pedersen (at) comcast (dot) net>
=== Expected outcomes ===
* Allow users to configure pgagroal in a more secure way
=== References ===
[1] https://github.com/agroal/pgagroal
[2] https://agroal.github.io/pgagroal/
[3] https://www.postgresql.org/
Category:Google Summer of Code