USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksBackend Book
HomeBackend BookData and State
PreviousPostgreSQL as the System of RecordNextSQLAlchemy, Repositories, and Units of Work
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

13 sections

Progress0%
1 / 13

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 Modeling, Constraints, and Indexes

A relational model encodes business facts and impossible states close to the data. Primary keys establish identity, foreign keys preserve references, checks restrict valid values, unique constraints prevent duplicates, and indexes support measured query patterns. Tenant ownership must be represented so every relationship and query can preserve isolation.

What will you be able to do?

  • translate SupportDesk AI concepts into normalized tables;
  • enforce invariants with database constraints;
  • design tenant-leading indexes for actual access paths;
  • use EXPLAIN evidence instead of index folklore.

What is the minimal tenant-safe schema?

sql
CREATE TABLE organizations ( id uuid PRIMARY KEY, name text NOT NULL CHECK (length(trim(name)) > 0), created_at timestamptz NOT NULL DEFAULT now() ); CREATE TABLE tickets ( id uuid PRIMARY KEY, organization_id uuid NOT NULL REFERENCES organizations(id), subject text NOT NULL CHECK (length(subject) BETWEEN 1 AND 120), body text NOT NULL CHECK (length(body) BETWEEN 1 AND 10000), status text NOT NULL CHECK (status IN ('open', 'in_progress', 'resolved')), version integer NOT NULL DEFAULT 1 CHECK (version > 0), created_at timestamptz NOT NULL DEFAULT now(), updated_at timestamptz NOT NULL DEFAULT now(), UNIQUE (organization_id, id) ); CREATE INDEX tickets_tenant_created_idx ON tickets (organization_id, created_at DESC, id DESC);

Using timestamptz stores an instant; convert to a user's timezone at the presentation boundary. Application code must still update updated_at, or a database trigger must own it consistently.

How do you design cross-tenant-safe relationships?

If a child table contains both organization_id and ticket_id, use a composite foreign key to (organization_id, id) so a row cannot pair tenant A with tenant B's ticket. This is defense in depth; application queries must also carry tenant predicates. PostgreSQL row-level security may add another control when implemented and tested carefully.

When does an index help?

An index trades write cost and storage for faster matching and ordering. Design it from the exact query predicate and order. Use representative data and:

sql
EXPLAIN (ANALYZE, BUFFERS) SELECT id, subject, status, created_at FROM tickets WHERE organization_id = '00000000-0000-0000-0000-000000000001' ORDER BY created_at DESC, id DESC LIMIT 26;

Do not run ANALYZE casually against a write statement in production; it executes the statement.

Why does this matter in AI-native systems?

Knowledge documents, chunks, embeddings, AI runs, and citations all require tenant ownership and lineage. A vector similarity result is not authorization. Join or filter through tenant and access metadata before content becomes model context.

Common mistakes

  • Using a model-generated natural key as primary identity.
  • Adding indexes to every column without workload evidence.
  • Storing comma-separated identifiers in text instead of relations.
  • Soft deletion without adjusting uniqueness and every query.
  • Assuming an ORM relationship guarantees tenant isolation.

AI Pair-Programmer Prompt

text
Review this PostgreSQL schema from business invariants and query patterns. Find states the database still allows, cross-tenant reference risks, nullable ambiguity, uniqueness scope, time semantics, deletion policy, index write cost, and EXPLAIN experiments. Do not add indexes without naming the query they support.

Exercise

Design users, memberships, and ticket_comments. Enforce unique membership per organization and prevent a comment from referencing a ticket in another tenant.

Acceptance criteria: invalid SQL inserts prove every key/check constraint; the ticket-list query uses its intended index on representative data.

Knowledge check

  1. Why lead the list index with organization_id?
  2. What does a foreign key guarantee?
  3. Does vector similarity grant access?

Answers

  1. Every authorized query starts within one tenant and then follows the required order.
  2. Referenced identity exists according to the defined key; composite keys can also preserve tenant pairing.
  3. No; authorization filters are independent and mandatory.

Completion checklist

  • Impossible states have constraints.
  • Cross-tenant references are prevented.
  • Indexes name the queries they serve.

Primary references

  • PostgreSQL constraints
  • PostgreSQL indexes
  • Using EXPLAIN