1.1General Characteristics of OSS-DB

The first step in OSS-DB Silver is correctly understanding PostgreSQL both as software and as a project. Before memorizing SQL syntax or operational commands, grasp the foundation that makes this OSS reliable over the long term: its license, its community, and how it manages versions. That foundation speeds up everything in the later chapters on operations and SQL.

1.1.1PostgreSQL feature overview and licensing

• PostgreSQL is an object-relational database management system (ORDBMS). It has high conformance to standard SQL and a full set of serious RDBMS features—advanced data types such as JSON/JSONB, arrays, and extension types, plus triggers, views, and stored procedures.
• Key capabilities: reliable ACID-compliant transactions (atomicity, consistency, isolation, durability), and MVCC (multi-version concurrency control) that gives high concurrency where reads do not block writes. It also conforms closely to standard SQL and is extensible via add-on extensions.
• OSS (open source software) is software whose source code is public and that anyone may use, modify, and redistribute. The PostgreSQL license is a permissive license with this character—it does not impose heavy restrictions on commercial use or on closing the source after modification.
• In practice, a permissive license means cloud vendors are free to offer their own PostgreSQL-compatible managed services, and companies can embed a modified version in their products with few restrictions. This freedom is a major reason the PostgreSQL ecosystem is so diverse.

1.1.2Community, versioning, and support

• PostgreSQL's community is not run by a single company—development proceeds through a distributed, global community of developers and companies worldwide. Its main activities include mailing-list discussion, submitting and reviewing patches, and conference talks.
• There are many entry points to participate in the community: subscribing to mailing lists, reporting bugs or improvement requests, translating documentation, or contributing patches. Its openness means anyone can join the discussion without a special approval process.
• A major version (e.g., 12 → 13 → 14) is a big update that can include new features and behavior changes. A minor version (e.g., 14.1 → 14.2) stays within the same major version and contains only bug and security fixes—new features are not added.
• The release cycle: a new major version ships roughly once a year. The support policy: each major version receives minor-version updates (bug and security fixes) for about five years after its release.
• A bug report is submitted through the community's bug tracker (which forwards to a mailing list via a web form), including reproduction steps, the version, and environment details. Accurate reports from users are a key input to improving quality.

Picture a team deciding when and how to update PostgreSQL in production. Suppose the running version is 12.10—that means major version 12, minor version 10. To pick up only security fixes, updating to the next minor release (e.g., 12.11) is enough, with almost no impact on application compatibility. Upgrading across major versions, from 12 to 13 or 14, however, involves new features and internal behavior changes, so the team must check the release notes and verify the application in a test environment beforehand. The team also plans around the support policy: if the running major version is approaching five years since release, they must plan a move to the next major version before end-of-life (EOL). If unexpected behavior (a bug) turns up during operation, the team first checks whether it is already a known issue via the community, and if not, compiles reproduction steps, the version, and OS environment details into a bug report. This combination—license freedom, an open community, and clear versioning with a defined support window—is what lets companies plan long-term operation with confidence.

1.1.3Section summary

• PostgreSQL = an ORDBMS with advanced types (JSON/JSONB, etc.), triggers, views, and more. Its license is permissive, with no obligation to publish modified source
• The community is distributed (not tied to a single company). Anyone can participate—mailing lists, patches, bug reports, and more
• Major = new features / minor = fixes only. Release cycle is annual; support lasts about five years