GSoC 2026
This page is for Google Summer of Code 2026 project ideas.
IF YOU ARE A MENTOR: there is a top-level GSoC page for PostgreSQL here: PostgreSQL General GSoC Page - please read this first before proceeding to contact the admins! PLEASE make sure you have read everything thoroughly.
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.
Note on Project Selection and Mentor Availability
Please be aware that the list of ideas below is a starting point. Due to the competitive nature of GSoC:
- Not all ideas will be funded. Google provides us with a limited number of "slots," and we can only accept the highest-quality proposals as determined by our mentors.
- Mentor Bottlenecks: Primary mentors will only take on one contributor. If several people apply for ideas listed under the same mentor, only the strongest application will be selected.
- Be Selective: We encourage you to check our communication channels (e.g., Slack) to see if many other contributors are already targeting a specific idea
Mentors mailing list for proposals: gsoc-mentors@lists.postgresql.org
Status
PostgreSQL has been accepted for Google Summer of Code 2026
Admins
- Jesper Pedersen <jesperpedersen (dot) db (at) gmail (dot) com>
- Pavlo Golub <pavlo (dot) golub (at) gmail (dot) com>
Mentors
The following individuals have been listed as mentors on the below projects:
- Pavlo Golub
- Jesper Pedersen
- Mark Wong
- Ahmed Gouda
- Luca Ferrari
- Tejas Tyagi
- Haoran Zhang
- Mohab Yassar
- Ashutosh Sharma
- Bassam Adnan
- Konstantina Skovola
- Akshat Jaimini
- Sachin Beniwal
- Arth Thapa
- Nik Samokhvalov
- Kirk Wolak
- Andrei Lepikhov
- Andreas Karlsson
Results
- Projects submitted: 14
- Mentors: 18
- Submissions: 193
- Projects approved: 11
- Google approved: 7
pgagroal: Advanced security
Project Description
The goal of this project is to add advanced security functionality to pgagroal.
The main focus is to add full pooling support for pgagroal to PostgreSQL communication. Note, that this might require a clean-room TLSv1.2+ implementation where we can cache and update the security context. Additionally areas such as client certificate authentication, SCRAM-SHA-256-PLUS and enhanced vault security can be investigated.
Skills needed
- C
- Transport Layer Security (TLS)
- PostgreSQL
Difficulty level
- Hard
Project size
- Large (350 hours).
Mentors
- Tejas Tyagi <tejastyagi (dot) tt (at) gmail (dot) com>
- Luca Ferrari <fluca1978 <at> gmail (dot) com>
Contact mentors for submission requirements.
Expected outcomes
- End-to-end TLS communication from client to PostgreSQL with pooling support
References
- pgagroal: https://github.com/pgagroal/pgagroal
pgmoneta: Model Context Server implementation
Project Description
The goal of this project is to enhance the Model Context Protocol server for pgmoneta.
The main focus is to support all the commands of pgmoneta, and their parameters. And, the requirements outside the commands such as security.
Part of the implementation should make it easy to test the functionality when new functionality is added to pgmoneta
Skills needed
- Rust
- PostgreSQL
Difficulty level
- Moderate
Project size
- Large (350 hours).
Mentors
- Haoran Zhang <andrewzhr9911 (at) gmail (dot) com>
- Jesper Pedersen <jesperpedersen (dot) db <at> gmail (dot) com>
Contact mentors for submission requirements.
Expected outcomes
- A MCP server that support all the pgmoneta CLI commands
References
pgmoneta: Write-Ahead Log (WAL) & Model Context Server (MCP)
Project Description
The goal of this project is to enhance the Write-Ahead Log (WAL) functionality of pgmoneta and its tools. Especially pgmoneta-walfilter. This work will include expanding the test cases, and making sure that PostgreSQL 14 to PostgreSQL 19 are fully supported.
This project also need to implement WAL functionality into the Model Context Protocol (MCP) server in order to create WAL streams for recovery in an easy way.
Skills needed
- C
- Rust
- PostgreSQL
Difficulty level
- Moderate
Project size
- Large (350 hours).
Mentors
- Mohab Yaser <mohabyaserofficial2003 (at) gmail (dot) com>
- Haoran Zhang <andrewzhr9911 (at) gmail (dot) com>
Contact mentors for submission requirements.
Expected outcomes
- Enhance pgmoneta-walfilter, increase code coverage of WAL generation and support WAL based commands in the MCP server
References
pgmoneta: Storage engines
Project Description
The goal of this project is to implement support for using external storage engines - such as SSH and S3 - for all of pgmoneta's commands.
The main focus is to create a unified interface that can be used across all storage engines to minimize integration into the pgmoneta infrastructure.
It should be possible to use one or more storage engines per cluster setup.
Skills needed
- C
- PostgreSQL
Difficulty level
- Hard
Project size
- Large (350 hours).
Mentors
- Jesper Pedersen <jesperpedersen (dot) db (at) gmail (dot) com>
- Haoran Zhang <andrewzhr9911 (at) gmail (dot) com>
Contact mentors for submission requirements.
Expected outcomes
- Unified storage engine interface, and a full implementation of one or more engines
References
- pgmoneta: https://github.com/pgmoneta/pgmoneta
pgexporter: Historic data
Project Description
The goal of this project to add a history to pgexporter such that metrics are stored over time based on the configuration. Backends should be sqlite, PostgreSQL or TimescaleDB.
This data can then be used to look at trends through reports or UIs, or even a Model Context Protocol (MCP) server.
Skills needed
- C
- Prometheus
- PostgreSQL
Difficulty level
- Moderate
Project size
- Large (350 hours).
Mentors
- Bassam Adnan <mailbassam (at) gmail (dot) com>
- Jesper Pedersen <jesperpedersen (dot) db (at) gmail (dot) com>
Contact mentors for submission requirements.
Expected outcomes
- Infrastructure for historic data that can be retrieved through various UIs
References
- pgexporter: https://github.com/pgexporter/pgexporter
B-tree Index Bloat Reduction (Page Merge)
Project Description
The project focuses on implementing efficient B-tree index bloat reduction through page merging. B-tree indexes can become severely bloated after heavy UPDATE/DELETE workloads - in production systems, indexes with 90%+ bloat are common.
Current solutions have significant drawbacks:
- REINDEX: Requires AccessExclusiveLock for entire duration (blocks all access)
- REINDEX CONCURRENTLY: Very long duration, requires 2x disk space
- pg_repack: External tool, complex setup, requires double space
This project would implement in-core page merging that:
- Merges sparsely populated leaf pages with their neighbors
- Uses two-phase locking (light lock for planning, brief exclusive lock for execution)
- Provides crash safety through WAL logging
- Achieves 30-50% bloat reduction with minimal disruption
A prototype extension (pg_btree_compact) has been developed demonstrating the approach. This project would work toward integrating similar functionality into core PostgreSQL, potentially as part of VACUUM or as a new REINDEX variant.
Skills needed
- C programming
- PostgreSQL
- B-Tree structures
Difficulty level
Hard
Project size
Large: approximately ~350 hours of work.
Mentors
- Kirk Wolak <wolakk (at) gmail (dot) com>
- Nik Samokhvalov <nik (at) postgres (dot) ai>
- Andrei Lepikhov <lepihov (at) gmail (dot) com>
Expected outcomes
- Working implementation of B-tree page merging
- Integration with VACUUM or as standalone command
- Proper WAL logging for crash safety
- Minimal exclusive lock duration (<1ms per 100 page merges)
- Performance benchmarks and bloat reduction measurements
- Comprehensive tests using amcheck for index integrity verification
References
Monitoring Tools Performance: pg_stat_statements and LWLock Contention
Project Description
The project focuses on improving the performance and reducing lock contention in PostgreSQL's monitoring infrastructure, particularly pg_stat_statements and related statistics collectors. Keeping in mind that the more executing backends you have running queries need to lock this structure for writing. Then monitoring software needs to lock this structure for reading. The faster the system, the more locking/unlocking takes up most of the time. Also, as the number of statements being tracked increases, the reading takes longer. Finally, sampling could reduce some of this.
pg_stat_statements is essential for query performance analysis, but it has known scalability issues:
- Lock contention: High-frequency queries cause contention on the shared hash table
- Memory pressure: Limited entries (default 5000) cause eviction churn on busy systems
- Reset overhead: pg_stat_statements_reset() can cause significant pauses
Similar issues affect other monitoring tools:
- pg_stat_activity updates
- pg_stat_user_tables/indexes statistics
- Custom statistics collectors
Goals of this project:
- Analyze and profile current lock contention patterns
- Implement lock-free or reduced-lock data structures where possible
- Add partitioned/sharded hash tables for better scalability
- Consider/test ideas on timing out (and not logging) if having to wait too long for the lock
- Consider/test a secondary queue for things to add when we have time
- Consider/test a circular buffer so reading always returns the previous portion of the buffer w/o locking
- Improve statistics aggregation efficiency
- Reduce impact on production workloads
This work is critical for observability in high-throughput PostgreSQL deployments where monitoring overhead must be minimized.
Skills needed
- C programming
- Performance profiling
- Concurrency/locking patterns
- PostgreSQL
Difficulty level
Hard
Project size
Large: approximately ~350 hours of work.
Mentors
- Kirk Wolak <wolakk (at) gmail (dot) com>
- Nik Samokhvalov <nik (at) postgres (dot) ai>
- Andrei Lepikhov <lepihov (at) gmail (dot) com>
Expected outcomes
- Measurable reduction in lock contention for pg_stat_statements
- Improved scalability under high query rates (target: 100k+ queries/sec)
- Benchmarks comparing before/after performance
- Documentation of new architecture and trade-offs
- Regression tests ensuring correctness of statistics collection
