---
title: "01 — PostgreSQL Origins: Why an Object-Relational Database"
uid: postgresql-origins
tags: ["database", "roadmap:postgresql-dba", "postgresql", "object-relational", "rdbms", "fundamentals"]
excerpt: "PostgreSQL is an object-relational system — strict typed relations plus user-defined types, inheritance, and functions. That load-bearing label explains the JSON columns, custom types, and extensions that look like bolt-ons."
date: 2026-08-13T03:27:53+0000
source: https://www.aveshina.my.id/en/blog/postgresql-origins
---

"Just another database, pick whichever" was how I filed PostgreSQL, and the label that matters got lost in the shrug. The idea everything else hangs off: **PostgreSQL is an object-relational database management system (ORDBMS), and that "object-relational" label is load-bearing.** It stores data in strict, typed relations like any RDBMS, but it extends that model with user-defined types, inheritance, and functions the way an object-oriented system would [1]. Once I separated "relational" from "object-relational," most of Postgres's odd quirks — JSON columns, custom types, extension ecosystem — stopped feeling like bolt-ons and started feeling like the point.

## What a relational database is, stripped down

The relational model is older than I assumed. E.F. Codd proposed it in 1970: data lives in **relations** (tables), each a set of **tuples** (rows), each tuple a set of typed **attributes** (columns) [2]. The word "relational" does not mean "tables relate to each other." It means each table is itself a mathematical relation — a set of rows conforming to a schema. Foreign keys and joins are conveniences built on top of that, not the definition.

PostgreSQL follows this model faithfully and adds the object layer on top, which is what the next notes cover. The reason I had to nail this down is the constant comparison that comes next: why relational at all, and why Postgres in particular against the NoSQL wave.

```figure
<svg viewBox="0 0 740 280" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Two-axis comparison. Horizontal axis: schema flexibility from rigid (left) to flexible (right). Vertical axis: consistency guarantee from eventual (bottom) to strong ACID (top). PostgreSQL sits top-left with a table grid icon and strong ACID label. MongoDB/Cassandra sit bottom-right with a document blob icon and eventual label. Arrows on each axis.">
  <defs>
    <marker id="oarrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">

    <!-- axes -->
    <line x1="80" y1="230" x2="680" y2="230" stroke="#94a3b8" stroke-width="1.5" marker-end="url(#oarrow)"/>
    <line x1="80" y1="230" x2="80" y2="40" stroke="#94a3b8" stroke-width="1.5" marker-end="url(#oarrow)"/>
    <text x="380" y="265" font-size="12" font-weight="700" fill="#475569" text-anchor="middle">schema flexibility  →</text>
    <text x="50" y="135" font-size="12" font-weight="700" fill="#475569" text-anchor="middle" transform="rotate(-90 50 135)">consistency  →</text>

    <!-- axis labels -->
    <text x="110" y="248" font-size="10" fill="#94a3b8" text-anchor="middle">rigid schema</text>
    <text x="640" y="248" font-size="10" fill="#94a3b8" text-anchor="middle">schema-less</text>
    <text x="95" y="220" font-size="10" fill="#94a3b8">strong ACID</text>
    <text x="95" y="60" font-size="10" fill="#94a3b8" text-anchor="start">eventual</text>

    <!-- PostgreSQL (top-left) -->
    <rect x="110" y="60" width="140" height="60" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="180" y="84" font-size="13" font-weight="700" fill="#052e16" text-anchor="middle">PostgreSQL</text>
    <text x="180" y="102" font-size="10" fill="#052e16" text-anchor="middle">typed relations</text>
    <text x="180" y="116" font-size="10" fill="#052e16" text-anchor="middle">+ ACID, JSON, types</text>

    <!-- NoSQL (bottom-right) -->
    <rect x="500" y="170" width="140" height="60" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
    <text x="570" y="194" font-size="13" font-weight="700" fill="#422006" text-anchor="middle">Mongo / Cassandra</text>
    <text x="570" y="212" font-size="10" fill="#422006" text-anchor="middle">documents / wide rows</text>
    <text x="570" y="226" font-size="10" fill="#422006" text-anchor="middle">eventual, horizontal scale</text>
  </g>
</svg>
```

## The case for relational: ACID is not optional decoration

The benefit I kept underestimating is data integrity. A relational system enforces a **schema** at write time — a column declared INTEGER NOT NULL rejects anything that isn't an integer, period. Add foreign keys, unique constraints, and check constraints, and the database itself becomes the guarantor of correctness, not whatever application code happens to be writing at the time [3]. That guarantee is bundled into **ACID**: Atomicity (a transaction is all-or-nothing), Consistency (the database moves from one valid state to another), Isolation (concurrent transactions don't see each other's half-finished work), Durability (committed data survives a crash) [4].

The cost is honest about itself. RDBMSs scale **vertically** well — bigger box, more RAM — and **horizontally** with real difficulty, because splitting a relational graph across machines breaks the joins and transactions that make it valuable. Schema changes are coordinated migrations, not silent drift [3]. For unstructured, very-high-velocity, globally-distributed data, NoSQL's trade of consistency for scale is the right call. For most application data — users, orders, accounts, content — the integrity guarantee earns its keep.

## PostgreSQL vs NoSQL, and the JSON escape hatch

The comparison that used to paralyze me was Postgres vs MongoDB. The framing that resolved it: **Postgres optimizes for correctness and complex relationships; NoSQL optimizes for scale and schema flexibility** [5]. MongoDB stores flexible JSON-like documents and shards horizontally by default; Postgres stores typed rows and shines on complex queries, joins, and transactions.

What dissolved the false dichotomy for me is that PostgreSQL has first-class **JSON and JSONB** types. A column can hold semi-structured documents, be indexed, and be queried with JSON-path operators — so the "I need flexible documents" use case doesn't automatically force a NoSQL choice [1][5]. The decision becomes: do I need horizontal scale and schema drift that badly, or is JSONB inside a transactional, typed database enough? For my work, it almost always is.

## PostgreSQL vs the other RDBMSs

Among relational systems, Postgres's differentiators are its open-source license, its extensibility, and its feature depth [6]:

- **vs Oracle / SQL Server** — Postgres is free and open-source, and it lets users define custom data types, operators, and functions. The proprietary systems are polished and supported, but Postgres matches or exceeds them on functionality.
- **vs MySQL** — MySQL is fast and popular for read-heavy, simple workloads; Postgres prioritizes feature richness and strict ACID compliance. Complex queries, window functions, advanced indexing, full-text search, and GIS via PostGIS all lean Postgres [6].

The extensibility is the part I now treat as the headline feature. PostGIS for geo data, pg_stat_statements for query stats, custom types for domain logic — the database is a platform, not a fixed product [1].

## How I use this

The practical payoff is a decision check. When I reach for a database, I ask two questions: does the data have natural relationships and integrity rules I want enforced, and do I need complex queries or transactions. If yes, Postgres is the default and I reach for JSONB columns when a slice of the data is genuinely semi-structured. If the entire workload is unstructured, globally scaled, and consistency-tolerant, NoSQL earns its place. I no longer default to whichever database the framework tutorial happened to use — the model, not the marketing, picks.

## References

[1] PostgreSQL Global Development Group, "PostgreSQL Documentation," 2024. [Online]. Available: [https://www.postgresql.org/docs/](https://www.postgresql.org/docs/)

[2] IBM, "What is a relational database?," 2024. [Online]. Available: [https://www.ibm.com/cloud/learn/relational-databases](https://www.ibm.com/cloud/learn/relational-databases)

[3] Internshala, "15 Advantages and Disadvantages of RDBMS," 2023. [Online]. Available: [https://trainings.internshala.com/blog/advantages-and-disadvantages-of-rdbms/](https://trainings.internshala.com/blog/advantages-and-disadvantages-of-rdbms/)

[4] Fauna, "What is ACID compliance? Atomicity, Consistency, Isolation," 2023. [Online]. Available: [https://fauna.com/blog/what-is-acid-compliance-atomicity-consistency-isolation](https://fauna.com/blog/what-is-acid-compliance-atomicity-consistency-isolation)

[5] AWS, "What's the difference between MongoDB and PostgreSQL?," 2024. [Online]. Available: [https://aws.amazon.com/compare/the-difference-between-mongodb-and-postgresql/](https://aws.amazon.com/compare/the-difference-between-mongodb-and-postgresql/)

[6] Integrate.io, "PostgreSQL vs MySQL: The critical differences," 2023. [Online]. Available: [https://www.integrate.io/blog/postgresql-vs-mysql-which-one-is-better-for-your-use-case/](https://www.integrate.io/blog/postgresql-vs-mysql-which-one-is-better-for-your-use-case/)

```quiz
Q: What does the "object-relational" in ORDBMS add on top of a plain RDBMS?
- Tables, rows, and columns
- User-defined types, inheritance, and functions
- Horizontal scaling across many machines
correct: 1
explain: The relational part gives typed tables; the object part adds user-defined types, inheritance, and functions, letting the database be extended like an object-oriented system.

Q: In Codd's relational model, what does "relational" actually refer to?
- The foreign-key links between tables
- Each table being a mathematical relation — a set of typed tuples
correct: 1
explain: A relation is a set of tuples conforming to a schema. Foreign keys and joins are built on top of that model, not the definition of "relational."

Q: ACID guarantees Atomicity, Consistency, Isolation, and Durability. Which property ensures a committed transaction survives a crash?
- Atomicity
- Consistency
- Isolation
- Durability
correct: 3
explain: Durability means once a transaction is committed, its changes persist even if the system crashes immediately after.

Q: You need to store mostly structured user/order data but one field is a flexible JSON document. The model that fits best is…
- MongoDB, because any flexibility means full NoSQL
- PostgreSQL with a JSONB column for the flexible field
correct: 1
explain: PostgreSQL's JSONB type handles semi-structured data inside a transactional, typed database, so the flexible slice doesn't force abandoning relational integrity.

Q: A key reason Postgres is favored over MySQL for complex workloads is…
- It is proprietary and commercially supported
- It has richer features, stricter ACID compliance, and stronger query capabilities
correct: 1
explain: MySQL favors speed in simple read-heavy cases; PostgreSQL prioritizes feature depth, advanced indexing, window functions, and strict ACID behavior.
```