Module 1 – PostgreSQL Foundations
Lesson 3 – PostgreSQL Development Model
Introduction
One of the most important differences between Oracle Database and PostgreSQL has nothing to do with SQL syntax, storage structures, memory management, replication, or performance.
The difference lies in how the database software itself is developed.
Oracle Database is engineered, tested, packaged, and released by Oracle Corporation through an internal product-development process. Customers can observe the resulting features and published documentation, but most design discussions, source-code reviews, implementation decisions, and internal testing remain within the company.
PostgreSQL follows a fundamentally different model.
Its source code is publicly available. Technical proposals are discussed on public mailing lists. Patches can be inspected and tested by the community. Reviews often happen in public, and the status of many proposed changes can be followed through the PostgreSQL CommitFest application.
This does not mean PostgreSQL development is informal or uncontrolled.
On the contrary, PostgreSQL has a mature development process involving contributors, reviewers, committers, release teams, governance groups, automated testing systems, mailing lists, CommitFests, beta releases, release candidates, and long-term maintenance branches.
Understanding this model helps a DBA evaluate new features, interpret release notes, plan upgrades, assess feature maturity, and understand how PostgreSQL maintains engineering discipline without being controlled by one software company.
Why This Lesson Matters
A production DBA should understand not only how a database behaves, but also how changes enter the software.
The development model affects:
Feature maturity
Release predictability
Upgrade planning
Bug-fix availability
Security maintenance
Documentation quality
Compatibility expectations
Community participation
Long-term support decisions
It also answers several practical questions:
Who decides whether a PostgreSQL feature is accepted?
What is the difference between a contributor and a committer?
What exactly happens during a CommitFest?
Why do some features remain under discussion for years?
Why does PostgreSQL release a new major version annually?
What is the difference between a major and minor release?
How are older PostgreSQL versions maintained?
Can a company unilaterally control PostgreSQL’s roadmap?
These questions become increasingly relevant as soon as PostgreSQL moves from a learning environment into production.
Who Should Read This?
This lesson is valuable for:
Oracle DBAs transitioning to PostgreSQL
PostgreSQL administrators planning upgrades
Engineers evaluating future PostgreSQL features
Developers interested in contributing to PostgreSQL
Architects selecting supported PostgreSQL versions
Technical leaders comparing commercial and community development models
No source-code experience is required.
Learning Objectives
By the end of this lesson, you should understand:
How PostgreSQL development is organized
What the PostgreSQL Global Development Group represents
Why no single company controls the PostgreSQL project
The roles of users, contributors, reviewers, committers, and governance teams
What a PostgreSQL patch represents
How development discussions happen
What the CommitFest process does—and does not do
How a proposed feature reaches a release
How PostgreSQL source branches are maintained
The difference between major and minor PostgreSQL releases
Why PostgreSQL’s release quality depends on process rather than ownership
A Necessary Clarification: Who Owns PostgreSQL?
The statement “nobody owns PostgreSQL” is common, but technically imprecise.
A better explanation is:
No single company owns or controls the PostgreSQL project, its technical roadmap, or its development community.
PostgreSQL is released under the PostgreSQL License, a permissive open-source licence. Its development is carried out by a global community operating under the broad identity of the PostgreSQL Global Development Group, commonly abbreviated as PGDG.
The PGDG is not a commercial software vendor equivalent to Oracle Corporation.
It is an umbrella identity used by the PostgreSQL project and its worldwide community.
Individual contributors retain rights associated with their contributions under the project’s licence and contribution framework. Various organizations also provide infrastructure, sponsorship, legal support, events, engineering time, packaging, consulting, and commercial services.
However, no participating company can independently dictate what enters the PostgreSQL core.
The project’s governance directory identifies multiple teams and committees, with the PostgreSQL Core Team acting as the central arbiter of project policy and governance.
PostgreSQL Is Community-Developed, Not Company-Developed
A simplified comparison helps establish the difference.
Commercial Product Development
Customer Requirements
│
▼
Product Management
│
▼
Internal Engineering
│
▼
Internal Review and Testing
│
▼
Vendor Release
PostgreSQL Development
Problem, Idea, or Patch
│
▼
Public Technical Discussion
│
▼
Patch Development
│
▼
Testing and Peer Review
│
▼
Author Revisions
│
▼
Committer Evaluation
│
▼
Commit, Defer, Return, or Reject
│
▼
Beta and Release-Candidate Testing
│
▼
Major Release
This second flow is intentionally simplified.
Not every change follows an identical path. Small bug fixes, documentation corrections, security fixes, and large architectural features may follow different review and release procedures.
The important point is that PostgreSQL development is largely visible.
Source-code access, developer resources, CommitFest information, contributor information, governance structures, release notes, and development discussions are available publicly.
PostgreSQL Community Roles Are Not a Strict Hierarchy
The handbook presents the following progression:
Users
↓
Contributors
↓
Reviewers
↓
Committers
↓
Core Team
This is helpful for showing increasing responsibility, but it must not be interpreted as a formal promotion ladder.
A person does not necessarily move through each stage in sequence, and the Core Team is not simply the “highest level of programmer.”
A more accurate model is:
PostgreSQL Community
│
┌───────────────┬───────────┼──────────────┬───────────────┐
▼ ▼ ▼ ▼ ▼
Users Contributors Reviewers Committers Project Teams
│
▼
Core, Release, Security,
Infrastructure, Advocacy,
Code of Conduct, and others
These roles overlap.
A committer may also be a contributor and reviewer. A user may review documentation or test a patch without writing C code. A Core Team member may be a highly experienced developer, but Core membership is a governance responsibility rather than the final stage of a coding career.
Role 1: PostgreSQL Users
Users are an essential part of PostgreSQL development, even when they never modify the source code.
They contribute by:
Reporting reproducible bugs
Testing beta and release-candidate versions
Describing production behaviour
Proposing improvements
Reviewing documentation
Helping other users
Testing patches
Translating documentation
Writing technical articles
Organizing community events
Operating BuildFarm members
Reporting performance regressions
Real production experience is especially valuable.
A feature may look correct in a laboratory but behave differently under:
High concurrency
Large databases
Unusual collations
Long-running transactions
Complex replication topologies
Different operating systems
Non-default configuration
Extension-heavy environments
Community testing helps expose such conditions before or after release.
Role 2: Contributors
A contributor is anyone who makes a meaningful contribution to the PostgreSQL project.
That contribution may include:
Source code
Bug fixes
Documentation
Regression tests
Performance improvements
Translation
Review work
Infrastructure
Community organization
Release testing
The PostgreSQL project also formally recognizes contributors and major contributors who have made substantial, sustained contributions over time. That recognition is different from being a committer.
Can Contributors Modify PostgreSQL?
Anyone can clone the public source repository and modify their own copy.
However, an ordinary contributor cannot directly write changes into the project’s authoritative repository.
Instead, proposed source-code changes are submitted for discussion and review. A committer must ultimately decide whether and how the change should be integrated.
What Is a Patch?
A patch represents a proposed change to an existing codebase.
At its simplest, it records the difference between an old version and a new version.
Original Code
return false;
Proposed Change
return true;
A real PostgreSQL patch may modify:
C source files
Header files
SQL definitions
Regression tests
Documentation
Catalog definitions
Build-system files
Expected test output
Upgrade-related metadata
A small bug fix may affect only a few lines.
A major feature may evolve through dozens of patch versions and touch many files over months or years.
A patch is therefore not merely “new code.” It is a reviewable proposal containing the implementation and, where required, tests and documentation needed to justify that implementation.
Role 3: Reviewers
Reviewers examine proposed changes before they are committed.
Review does not mean only reading C code.
A reviewer may help by:
Applying the patch
Verifying that it builds
Running regression tests
Testing the proposed behaviour
Checking error cases
Comparing performance
Reviewing SQL syntax
Checking documentation
Identifying compatibility concerns
Looking for concurrency problems
Evaluating code readability
Testing on different platforms
PostgreSQL’s own reviewer guidance emphasizes that useful review can begin with applying a patch and testing its behaviour. A reviewer does not need to be capable of evaluating every aspect of a complex patch before contributing value.
What Review Does Not Guarantee
A positive review does not automatically mean a patch will be committed.
A patch may still be deferred or rejected because:
The broader design is unsuitable
Another implementation is preferred
The maintenance cost is too high
The feature is too late for the release
The patch conflicts with other work
A committer discovers additional problems
The project cannot reach sufficient agreement
The author stops responding
Review improves a patch’s maturity; it does not create an entitlement to inclusion.
Role 4: Committers
Committers are trusted PostgreSQL developers authorized to commit changes to the project repository.
Their responsibility extends beyond pressing a merge button.
A committer must evaluate:
Technical design
Correctness
Code quality
Test coverage
Documentation
Portability
Maintainability
Compatibility
Error handling
Interaction with existing subsystems
Long-term project consequences
The PostgreSQL project states that new committers are selected from contributors with substantial, sustained involvement, technical ability, good judgment, collaborative behaviour, and demonstrated understanding of the project. Existing committers discuss and vote on new appointments.
Contributor Versus Committer
Contributor
Proposes and develops a change
Responds to review feedback
Revises the patch
May test and review other patches
Committer
Performs final technical evaluation
May modify the patch before committing
Accepts responsibility for repository changes
Can commit, defer, reject, or return the work
A committer does not merely validate the contributor’s effort.
The committer assumes responsibility for introducing the change into PostgreSQL.
Role 5: The PostgreSQL Core Team
The Core Team is frequently misunderstood.
It is not a board that personally approves every SQL feature or reviews every patch. Nor is it a management layer directing PostgreSQL developers like employees.
Its published responsibilities include:
Coordinating release activities
Making policy announcements
Managing certain permissions
Handling confidential communication
Addressing disciplinary matters
Making difficult decisions when consensus is unavailable
Supporting project-level governance
The Core Team acts as a central authority for policy and governance, not as the sole source of PostgreSQL’s technical roadmap.
Technical development remains distributed among contributors, reviewers, committers, subsystem experts, and project teams.
Where PostgreSQL Development Happens
PostgreSQL development uses several public channels.
The most important include:
PostgreSQL mailing lists
The public Git source repository
The CommitFest application
Developer documentation
Automated testing systems
The PostgreSQL BuildFarm
Bug-reporting channels
For core development, the pgsql-hackers mailing list is particularly important.
Large features are commonly introduced through technical discussion before or alongside patch submission.
Discussion may cover:
Problem definition
SQL semantics
User interface
Catalog design
Storage implications
WAL behaviour
Recovery behaviour
Concurrency
Replication
Security
Performance
Upgrade impact
Testing strategy
Documentation
Some proposals are resolved quickly.
Others may be debated, redesigned, split into smaller changes, or abandoned.
The Mailing List Is the Source of Technical Context
The CommitFest application is valuable, but it is not the sole source of truth for a patch.
The PostgreSQL CommitFest help page explicitly describes the application as a tracking tool for changes proposed on the mailing lists, comparable in some ways to a pull-request list. The mailing-list discussion remains the authoritative location for the technical conversation.
This matters because the CommitFest entry may show status, authors, reviewers, and links, but the reasoning behind a decision is often found in the associated email thread.
For a DBA or developer evaluating a future feature, both should be consulted:
CommitFest Entry
Status
Patch history
Participants
Links
+
Mailing-List Thread
Design rationale
Objections
Benchmarks
Alternatives
Failure cases
Reviewer feedback
Feature Development Lifecycle
Consider a hypothetical proposal for an automatic query-result cache.
A realistic high-level lifecycle might look like this:
Problem Identified
│
▼
Initial Design Discussion
│
▼
Prototype or Proof of Concept
│
▼
Patch Posted to Mailing List
│
▼
Patch Registered for CommitFest
│
▼
Testing and Peer Review
│
▼
Author Revises the Design
│
▼
Additional Review and Benchmarking
│
▼
Committer Evaluation
│
├── Committed
├── Returned with Feedback
├── Moved to Another CommitFest
├── Withdrawn
└── Rejected
Even after a feature is committed, its journey is not complete.
It must still survive:
Continuous integration
BuildFarm testing
Integration with other committed changes
Beta testing
Release-candidate testing
Documentation review
Real-world testing
Possible redesign or removal before final release
A committed feature can still expose defects before release and require substantial correction.
What Is a CommitFest?
A PostgreSQL CommitFest is a defined period during the major-release development cycle when contributors and committers focus heavily on reviewing, testing, updating, and processing registered patches.
The PostgreSQL developer site describes CommitFest as a period for getting patches reviewed, tested, and committed. The project typically holds several CommitFests during a major development cycle.
A helpful mental model is:
CommitFest is a structured patch-review window—not an automatic feature-approval event.
What CommitFest Provides
CommitFest helps the project with:
Patch registration
Status tracking
Reviewer coordination
Feedback
Testing
Visibility
Release-cycle organization
Prevention of unreviewed patch accumulation
Without structured tracking, patches could disappear into long mailing-list threads and remain unnoticed.
Common CommitFest Statuses
Statuses evolve with the tooling and process, but commonly encountered outcomes include:
Needs Review
The patch requires reviewer attention.Waiting on Author
Feedback has been provided and the author must respond or revise the patch.Ready for Committer
Reviewers believe the patch is mature enough for final committer evaluation.Committed
A committer has integrated the change.Moved to Next CommitFest
Work continues in a later review cycle.Returned with Feedback
The patch requires substantial further work outside the current cycle.Withdrawn
The author or community has withdrawn the proposal.Rejected
The proposal will not proceed in its current form.
A real CommitFest may contain hundreds of entries across features, bug fixes, documentation changes, and infrastructure work.
What “Ready for Committer” Actually Means
This status is often misunderstood.
It does not mean:
The patch has been approved and only needs to be merged.
It means:
Reviewers believe the patch is sufficiently developed for a committer to perform final evaluation.
The committer may still:
Find correctness problems
Request redesign
Modify the patch
Return it for more work
Decide that it is not appropriate
Delay it beyond the current release
Final integration authority remains with committers.
Why Some PostgreSQL Features Take Years
A long development period is not always a sign of poor project management.
Database features can affect multiple subsystems simultaneously.
For example, a seemingly simple feature may interact with:
SQL parsing
Catalog metadata
Planner costing
Executor behaviour
Transactions
Locking
WAL
Crash recovery
Logical replication
Physical replication
Backup
Upgrade paths
Extensions
Monitoring
Documentation
A feature may require multiple rounds of work because reviewers discover that its initial design solves only the obvious case.
Year 1
Problem Discussion
│
▼
Initial Prototype
│
▼
First Review
Year 2
Revised Architecture
│
▼
Concurrency Testing
│
▼
Performance Evaluation
Year 3
Further Simplification
│
▼
Final Review
│
▼
Commit or Deferral
However, time alone does not prove quality.
A patch that has existed for years may still be rejected. Conversely, a well-understood, narrowly scoped improvement may be accepted more quickly.
Maturity must be assessed through design quality, review, testing, and integration—not age.
Automated Testing and the PostgreSQL BuildFarm
Public review is only one part of PostgreSQL quality engineering.
PostgreSQL also uses automated testing across many platforms and configurations.
The PostgreSQL BuildFarm is a distributed system that builds and tests PostgreSQL on a wide variety of operating systems, architectures, compilers, and configurations. Its purpose is to detect failures that may not appear in a developer’s local environment.
A patch may work on one Linux machine but fail because of:
Compiler differences
Operating-system behaviour
Endianness
32-bit versus 64-bit architecture
Locale differences
Optional build flags
Timing-sensitive concurrency
Missing dependencies
Platform-specific code
The CommitFest ecosystem also uses automated tooling to detect whether registered patches still apply and pass continuous-integration checks as the development branch changes.
PostgreSQL Source-Code Branches
PostgreSQL source code is maintained using Git, and a public mirror of the source repository is available.
A simplified branch model looks like this:
master
Active development for the next major PostgreSQL release
│
├── New features
├── Architectural changes
├── Performance improvements
└── Documentation development
REL_18_STABLE
Maintenance branch for PostgreSQL 18
│
├── Bug fixes
├── Security fixes
└── Carefully selected corrections
REL_17_STABLE
Maintenance branch for PostgreSQL 17
│
├── Bug fixes
├── Security fixes
└── Carefully selected corrections
The important principle is:
New features normally enter the active development branch, not already released stable branches.
Stable branches receive fixes intended to preserve compatibility and reduce regression risk.
This branch discipline prevents a minor update from unexpectedly behaving like a new major release.
The PostgreSQL Release Lifecycle
A simplified major-release lifecycle is:
Active Development
│
▼
Feature Freeze
│
▼
Beta Releases
│
▼
Release Candidates
│
▼
Major Release
│
▼
Minor Maintenance Releases
│
▼
End of Support
Active Development
New features and substantial changes are developed and committed.
Feature Freeze
The project stops accepting normal new-feature work for that major release and shifts attention toward stabilization.
Beta Releases
Beta versions allow broader testing of:
New features
Upgrade behaviour
Application compatibility
Performance
Extensions
Documentation
Platform support
Release Candidates
Release candidates represent builds believed to be close to final release quality. Testing focuses on discovering release-blocking defects.
Major Release
The new feature release becomes generally available.
Maintenance Period
Supported major versions receive minor releases containing bug, security, and correctness fixes.
Major Versus Minor PostgreSQL Releases
This distinction is operationally critical.
Major Release
For PostgreSQL 10 and later, the first number identifies the major version.
Examples:
PostgreSQL 17
↓
PostgreSQL 18
A major release may introduce:
New SQL features
Planner improvements
Catalog changes
Configuration changes
New monitoring facilities
Replication improvements
Storage or internal-format changes
Removed or deprecated functionality
Behavioural changes
Moving between major versions requires a major-version upgrade method such as:
pg_dumpand restorepg_upgradeLogical replication
A managed-service migration mechanism
Applications, extensions, drivers, query plans, backup tools, replication, monitoring, and operating procedures should be validated.
Minor Release
For PostgreSQL 10 and later, the second number identifies the minor release.
Examples:
PostgreSQL 18.3
↓
PostgreSQL 18.4
Minor releases primarily deliver:
Bug fixes
Security fixes
Data-corruption fixes
Regression fixes
Stability corrections
They do not introduce normal new-feature sets.
The official versioning policy explains that minor releases preserve the same internal storage format within a major version. Administrators generally install updated binaries and restart the server rather than performing a dump-and-restore or pg_upgrade.
Minor Releases Are Not Optional Maintenance
A common production mistake is to remain indefinitely on an early minor release because the database appears stable.
This is risky.
Minor releases can fix:
Security vulnerabilities
Incorrect query results
Replication defects
Crash conditions
Data-corruption risks
Platform-specific problems
Regressions introduced by previous fixes
For example, PostgreSQL’s May 14, 2026 maintenance release updated all supported branches and included fixes for security vulnerabilities and more than sixty reported bugs.
The correct approach is:
Read Release Notes
│
▼
Assess Applicability and Risk
│
▼
Test in Representative Environment
│
▼
Validate Extensions and Tooling
│
▼
Schedule Controlled Deployment
│
▼
Monitor After Restart
“Minor release” means maintenance compatibility—not “no testing required.”
Supported-Version Policy
Each PostgreSQL major version is supported for five years.
During that period, the project issues bug and security fixes through minor releases. After end of support, the community no longer guarantees maintenance updates for that major line.
A production DBA should maintain a version inventory containing:
Cluster name
Environment
Major version
Minor version
Installation source
Support end date
Extension versions
Upgrade target
Planned upgrade window
Business owner
Recovery dependencies
Running an unsupported version is not merely a compliance concern.
It means newly discovered defects or security vulnerabilities may never be fixed for that branch.
Current Release Context
At the time this article is being prepared in July 2026:
PostgreSQL 18 is the current production major version.
PostgreSQL 19 is the active development line.
Supported production branches include PostgreSQL 14 through PostgreSQL 18.
This information is time-sensitive.
Always verify the official PostgreSQL versioning and release pages before making upgrade or support decisions.
Why PostgreSQL Releases Earn Trust
PostgreSQL’s reputation for stability does not come from one review meeting or one testing tool.
It is produced by overlapping controls:
Public Design Discussion
+
Peer Review
+
Committer Responsibility
+
Regression Tests
+
Continuous Integration
+
BuildFarm Testing
+
Beta Testing
+
Release-Candidate Testing
+
Stable-Branch Discipline
+
Minor Maintenance Releases
None of these mechanisms is perfect individually.
Together, they reduce the probability that one person, one company, one platform, or one test environment determines the quality of the entire database.
Stability Is Not the Same as Absence of Bugs
PostgreSQL releases can still contain:
Regressions
Security vulnerabilities
Planner mistakes
Platform-specific defects
Replication problems
Extension incompatibilities
Documentation errors
The project’s strength lies not in being defect-free, but in having transparent processes for discovering, discussing, correcting, and releasing fixes.
Oracle Versus PostgreSQL Development Model
| Area | Oracle Database | PostgreSQL |
|---|---|---|
| Source availability | Proprietary | Publicly available |
| Primary development organization | Oracle Corporation | Global PostgreSQL community |
| Roadmap control | Vendor-controlled | Distributed public development and committer decisions |
| Design discussion | Primarily internal | Frequently public through mailing lists |
| Code review | Internal engineering process | Community review plus committer evaluation |
| Source integration | Authorized Oracle engineers | PostgreSQL committers |
| Testing | Internal vendor QA and supported-platform validation | Regression tests, community testing, CI, BuildFarm, beta and RC testing |
| Governance | Corporate management | Project teams and governance groups |
| Maintenance delivery | Vendor patches and release updates | Community minor releases for supported branches |
| Commercial support | Oracle | Multiple independent PostgreSQL vendors and service providers |
This comparison should not be reduced to “closed is bad” and “open is good.”
Oracle’s model can provide:
Unified commercial accountability
Integrated support contracts
Coordinated product packaging
Certified technology stacks
Vendor-controlled engineering priorities
PostgreSQL’s model can provide:
Transparent technical discussion
Public source access
Multiple support providers
Broad participation
Independent review
Reduced control by a single vendor
Both models have strengths and trade-offs.
A DBA must understand the operating model behind the software being supported.
Why This Matters to a Production DBA
The development model directly affects operational decisions.
1. Evaluating a Future Feature
Do not treat a mailing-list proposal as a committed roadmap item.
Distinguish between:
Idea
Patch Submitted
Needs Review
Ready for Committer
Committed
Available in Beta
Included in Final Release
Only the final stages provide strong deployment certainty.
Even committed features should be tested during beta because behaviour can change before general availability.
2. Planning Major Upgrades
Review:
Major-release notes
Compatibility changes
Removed features
Parameter changes
Extension support
Query-plan changes
Driver certification
Backup compatibility
Replication design
Rollback strategy
3. Applying Minor Releases
Do not delay indefinitely.
Minor releases are the normal delivery mechanism for important bug and security fixes within a supported major version.
4. Investigating Bugs
Public archives may reveal:
Similar bug reports
Developer analysis
Proposed fixes
Back-patch discussion
Target maintenance release
Workarounds
This visibility can be valuable during production incidents, but uncommitted patches should not be applied casually to production systems.
5. Testing Beta Releases
Beta testing helps both your organization and the PostgreSQL project.
It can expose:
Application incompatibility
Extension failures
Performance regressions
Changed defaults
Driver problems
Monitoring gaps
Upgrade-tool issues
Discovering these problems before general release is far safer than discovering them during a production migration.
Practical DBA Checklist
Before adopting a new PostgreSQL major version:
Read the complete major-release notes.
Review migration and incompatibility sections.
Verify support dates.
Confirm extension compatibility.
Test
pg_upgrade, logical replication, or dump-and-restore procedures.Compare critical SQL execution plans.
Validate backup and restore tooling.
Test failover and replication.
Review parameter changes.
Confirm monitoring support.
Test drivers and connection poolers.
Document rollback criteria.
Before applying a minor release:
Read the minor-release notes.
Identify fixes relevant to your environment.
Review known regressions.
Validate extensions and packaged dependencies.
Test the binary update.
Confirm restart requirements.
Verify replication health afterward.
Monitor logs and critical workloads.
Common Misconceptions
“Nobody Owns PostgreSQL”
Imprecise.
No single company owns or controls the PostgreSQL project. PostgreSQL is released under an open-source licence and developed by a distributed community.
“The Core Team Approves Every Feature”
Incorrect.
The Core Team focuses on project policy and governance. Technical feature integration is primarily handled through contributors, reviewers, committers, and relevant experts.
“CommitFest Is Where Features Are Approved”
Incorrect.
CommitFest structures review and patch tracking. It does not guarantee commitment.
“Ready for Committer Means Accepted”
Incorrect.
It means reviewers consider the patch ready for final committer evaluation.
“Contributors Cannot Modify PostgreSQL”
Misleading.
Anyone may modify a local copy. Only authorized committers can integrate changes into the project repository.
“A Patch That Survives Several Years Must Be High Quality”
Not necessarily.
Long discussion may indicate complexity, disagreement, insufficient resources, or unresolved design problems.
“Minor Releases Contain Only Unimportant Fixes”
Incorrect.
They may contain security, correctness, crash, replication, and data-integrity fixes.
“Community-Developed Means Unsupported”
Incorrect.
The community maintains supported branches, while many independent companies offer commercial PostgreSQL support, tooling, hosting, and consulting.
Key Takeaways
PostgreSQL is not controlled by a single company.
The PostgreSQL Global Development Group represents the wider project community rather than a commercial corporation.
PostgreSQL community roles overlap and do not form a simple promotion ladder.
Contributors propose code, documentation, tests, reviews, and other improvements.
Reviewers test and evaluate patches but do not guarantee acceptance.
Committers are trusted developers authorized to integrate changes into the repository.
The Core Team is primarily responsible for policy and governance, not approving every technical feature.
Technical discussion commonly takes place on public mailing lists.
The CommitFest application organizes and tracks proposed changes, while mailing-list threads retain the main technical context.
New features normally enter the active development branch.
Stable branches receive bug, security, and carefully selected correctness fixes.
Major releases add features and require upgrade planning.
Minor releases maintain a major version and should be applied through a controlled patching process.
PostgreSQL quality comes from overlapping review, testing, release, and maintenance mechanisms.
What’s Next?
We now understand:
Where PostgreSQL came from
Which engineering values influence it
How its community turns ideas into production software
The next lesson establishes the vocabulary needed to understand its architecture correctly.
In Module 1 – Lesson 4: PostgreSQL Terminology, we will examine terms such as:
Server
Cluster
Instance
Database
Schema
Relation
Tuple
Backend
Role
Tablespace
Data directory
WAL
These terms may look familiar to an Oracle DBA, but several have very different meanings in PostgreSQL.
Understanding that vocabulary before entering the architecture module will prevent confusion later.
Series Navigation
Previous: Module 1 – Lesson 2: PostgreSQL Philosophy
Current: Module 1 – Lesson 3: PostgreSQL Development Model
Next: Module 1 – Lesson 4: PostgreSQL Terminology
References
PostgreSQL Developers Portal
PostgreSQL Project Governance Directory
PostgreSQL Core Team Charter and Responsibilities
PostgreSQL Committers
PostgreSQL CommitFest Application
PostgreSQL CommitFest Documentation
PostgreSQL Patch-Review Guidance
PostgreSQL Source-Code Repository Documentation
PostgreSQL BuildFarm
PostgreSQL Versioning Policy
PostgreSQL Release Notes
PostgreSQL Contributor Profiles and Recognition Policy
Author Note
For an Oracle DBA, PostgreSQL’s public development process may initially appear less centralized than a commercial software lifecycle.
That does not mean it lacks control.
Its control is distributed across technical review, committer responsibility, public accountability, automated testing, stable-branch policies, release management, and community governance.
Understanding this process changes how we interpret PostgreSQL features.
A proposed feature is not a promise. A CommitFest entry is not a release commitment. A committed patch is not a substitute for beta testing. A major release is not a routine patch. A minor release is not operationally unimportant.
A production PostgreSQL DBA must learn to read not only database metrics and execution plans, but also release notes, support policies, patch status, extension compatibility, and development context.
That awareness is part of administering a community-developed enterprise database responsibly.
No comments:
Post a Comment