PostgreSQL
App Definition & DeliveryPostgreSQL is an open-source relational database.
What it is
PostgreSQL is an open-source relational database. It's not a CNCF project, not a Kubernetes-native tool, and its GitHub mirror stats (used here for signal) undercount its real footprint — the canonical development happens on its own mailing lists and git.postgresql.org, with GitHub serving as a mirror. Category tag of "App Definition and Development" is a stretch; in practice it's the data layer underneath a huge share of stateful workloads, including plenty running on Kubernetes via operators (CloudNativePG, Zalando's postgres-operator, Crunchy PGO).
Who builds it and why
Maintained by the PostgreSQL Global Development Group — a loose, non-corporate community of core committers, many employed by companies with commercial interest in Postgres (EDB, Crunchy Data, Microsoft, AWS, Google, Percona) but no single vendor controls it. The 58 contributors figure on the GitHub mirror understates actual contribution volume; real development activity is tracked via commitfests and mailing list patches, not PRs. Motivation is straightforward: it's decades-old, ACID-compliant, extensible infrastructure that a huge portion of the industry depends on — the incentive to keep it correct and fast is existential for many of its maintainers' employers.
Production readiness signal
Not in question — Postgres has run production workloads for 25+ years across every scale imaginable. The GitHub star count (21,326) is misleading as a popularity signal since it's a mirror, not the primary repo. Last commit date (2026-07-01) reflects mirror sync activity, consistent with an actively maintained project. License is tagged NOASSERTION in this dataset, which is a metadata gap, not a licensing concern — Postgres uses the permissive PostgreSQL License (a liberal BSD/MIT-style license). Latest release info not publicly available here, but Postgres ships a major version yearly with a well-documented, predictable release and support policy (5 years per major version).
Who should use this
- Teams needing a relational database with strong consistency, mature SQL support, and rich extension ecosystem (PostGIS, pgvector, TimescaleDB).
- Platform teams running stateful workloads on Kubernetes who pair Postgres with an operator (CloudNativePG, PGO) instead of hand-rolling StatefulSets.
- Anyone who needs JSONB, full-text search, or vector search without standing up three separate specialized systems.
- Organizations that want to avoid proprietary database lock-in and retain full control over their data layer.
Who should NOT use this
- Teams needing multi-region active-active writes with minimal operational effort — Postgres replication (streaming, logical) works but isn't push-button multi-master; look at CockroachDB or Yugabyte instead.
- Extreme write-throughput, horizontally-sharded workloads at massive scale without engineering investment — you'll need Citus, Vitess-style sharding, or a purpose-built distributed database.
- Teams wanting a fully managed, zero-ops experience without any DBA/platform skill on staff — running Postgres well (vacuum tuning, connection pooling, backup/restore, failover) is real operational work, even with an operator.
- Pure key-value or document-store use cases where relational modeling adds no value — Redis or DynamoDB will be simpler and cheaper.
- Teams that need a managed serverless database with instant scale-to-zero — vanilla Postgres doesn't do this natively (though Neon/Aurora Serverless layer it on).
Alternatives
- MySQL/MariaDB — comparable relational feature set, larger footprint in web/CMS stacks, weaker JSON and extension ecosystem.
- CockroachDB — Postgres-wire-compatible, built for distributed/multi-region consistency out of the box, at the cost of operational complexity and licensing (BSL for some features).
- MongoDB — right choice if your data is genuinely document-shaped and you don't need multi-row transactions across collections as a first-class primitive.
Pricing
Fully open source under the PostgreSQL License (permissive, BSD/MIT-style). No paid tier, no feature gating. Cost comes from operations — self-hosting effort, or paying a managed provider (RDS, Cloud SQL, EDB, Crunchy Bridge, Neon, Supabase) for hosting and support.