USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksPostgreSQL Book
HomePostgreSQL BookFoundations
PreviousAbout This Book: Your PostgreSQL Zero-to-Expert PathNextInstall PostgreSQL and Build a Safe Learning Environment
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

17 sections

Progress0%
1 / 17

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

Relational Databases and AI-Native Truth

A relational database stores facts in tables and connects them through keys, while constraints and transactions keep those facts valid as many users work at once. PostgreSQL is the database engine; SQL is the language used to define, read, and change data. AI features consume this truth but do not redefine it.

What will you be able to do?

  • Distinguish a database, database management system, table, row, column, and SQL.
  • Explain relations, primary keys, foreign keys, constraints, and transactions.
  • Identify facts that are canonical versus derived.
  • Sketch the first relational boundary for SignalDesk AI.

Prerequisites

Only the study method from About This Book. No software is required for this chapter.

What is the mental model?

A spreadsheet is a useful grid owned by a human workflow. A database is a shared fact system that must answer three harder questions:

  1. What does each fact mean?
  2. Which states are impossible?
  3. What happens when changes overlap or fail halfway?

In the relational model, a table represents a set of facts of one kind. A row is one fact instance. A column defines one attribute and its allowed type. A primary key identifies a row. A foreign key asserts that a referenced row exists.

text
organizations id = 42, name = "Northstar Health" tickets id = 9001, organization_id = 42, subject = "Cannot sign in"

tickets.organization_id → organizations.id expresses more than matching numbers: the ticket must belong to a real organization.

What makes data relational?

“Relational” does not simply mean “tables have links.” It comes from relations: sets of tuples described by attributes and governed by predicates. SQL tables are practical implementations with details such as duplicate rows unless constrained, ordering only when requested, and NULL for missing or inapplicable values.

The important habit is to state a table as a sentence:

  • organizations: “Organization id has legal display name name.”
  • memberships: “User user_id belongs to organization organization_id with role.”
  • tickets: “Ticket id belongs to organization organization_id and currently has status.”

If the sentence is ambiguous, the schema will be ambiguous.

Which truth belongs in PostgreSQL?

For SignalDesk AI, canonical facts include the ticket, its organization, message authorship, document version, access policy, approval decision, and audit event. Derived data includes search vectors, embeddings, summaries, suggested replies, and roll-up metrics.

Derived data may also live in PostgreSQL, but it needs lineage:

Derived valueRequired lineage
Embeddingsource version, chunk, model, dimensions, created time
Summarysource records, prompt/model version, review status
Search rankquery, retrieval configuration, candidate identifiers
AI answerevidence identifiers, model/prompt version, trace, approval

If an embedding is deleted and rebuilt, the knowledge document remains truth. If the only source text was embedded and then discarded, recovery and citation become impossible.

Decision exercise: table, attribute, relationship, or derived value?

Classify each item:

  1. An organization’s billing name.
  2. A ticket’s current assignee.
  3. The number of open tickets this minute.
  4. A similarity score between a question and a chunk.
  5. The human approval that allowed a refund tool to run.

A defensible first answer is: attribute; relationship; derived query or maintained projection; ephemeral derived score; canonical auditable event. The exact model may vary, but the reason must not.

Why does this matter in AI-native systems?

Language models produce plausible text, not database invariants. A model may call a customer “active” while the account is suspended, merge two people with similar names, or cite a stale document. The application must ground model context in authorized relational facts and validate any proposed change against deterministic rules.

AI-native does not mean the model owns the data model. It means the data model includes the evidence, versions, policies, evaluations, and audit events needed to operate AI responsibly.

Prove your model is meaningful

For every proposed table, write:

  • the sentence each row asserts;
  • the candidate key that makes the assertion unique;
  • invalid states the database should reject;
  • who owns the fact;
  • whether it is canonical or rebuildable;
  • its retention and deletion rule.

If you cannot answer these, the table name is not yet a model.

Production judgment

  • Correctness: application validation improves messages; database constraints protect every writer.
  • Security: access decisions should reference stable identities and memberships, not model interpretation.
  • Reliability: canonical data needs backups, recovery objectives, and migration discipline.
  • Performance: normalized truth can be projected for read speed, but projections need refresh and verification.
  • Cost: duplicated derived data can be worthwhile; duplicated canonical truth creates reconciliation cost.

Common mistakes

SymptomCauseFix
One giant records table with JSON for everythingStructure was postponedModel stable identities, relationships, and invariants relationally
Names are used as identifiersHuman labels were confused with keysUse stable keys; make names changeable attributes
AI summary becomes the only stored recordDerived output replaced evidencePreserve the source and version the summary came from
“The app checks it” is the only guaranteeOther writers and races were ignoredAdd database constraints for durable invariants

AI Pair-Programmer Prompt

text
Review a proposed SignalDesk AI data concept. For each fact, ask me to state the row predicate, candidate key, owner, lifecycle, tenant boundary, and whether it is canonical or derived. Suggest tables only after identifying invariants. Do not generate executable DDL yet. Return ambiguities, competing models, tradeoffs, and questions I must answer. Do not treat model output, embeddings, summaries, or search ranks as canonical truth.

Hands-on exercise

Sketch four boxes for organizations, users, memberships, and tickets. Label the primary key in each and draw foreign-key arrows. Write one rejected state beside each box.

Acceptance criterion: your diagram can represent one user belonging to two organizations without duplicating the user, and a ticket cannot reference a nonexistent organization.

Knowledge check

  1. What is the difference between PostgreSQL and SQL?
  2. What assertion does a foreign key make?
  3. Why are embeddings derived data?
  4. Why is a table name insufficient as a model?

Answers

  1. PostgreSQL is a database management system; SQL is the language used to define and work with relational data.
  2. The referenced key exists in the referenced table, subject to the constraint’s timing and nullability.
  3. They are computed from source content by a particular model and can be rebuilt or become stale.
  4. A model also needs a row predicate, key, invariants, ownership, lifecycle, and truth classification.

Completion checklist

  • I can define the core database vocabulary.
  • I wrote row-predicate sentences for four SignalDesk facts.
  • I separated canonical from derived data.
  • My tenant relationship supports users in multiple organizations.

Primary references

  • PostgreSQL tutorial: relational database concepts
  • PostgreSQL tutorial: tables
  • PostgreSQL constraints