• Someone says "Kimball is dead, cloud fixes everything."
• Someone else says "Inmon is the only serious enterprise architecture."
• A third person slides in with "Data Vault 2.0 is the future—just add Hubs, Links, Satellites and boom: audit-ready agility."

And then… nothing gets built for six weeks. Everyone shows up with a favorite methodology, a few conference slides in their head, and one dangerous sentence: "We should standardize on the right approach."

Here's my promise: this post will help you pick an approach the way an architect picks a structure—not like a sports fan picking a jersey .

Kimball, Inmon, and Data Vault 2.0 are not three rival religions. They are three different answers to one architectural question:

Where do I want the pain to live?

• In the reporting layer, so business users get answers fast?
• In the enterprise integration layer, so the company has one governed backbone?
• In a historized core, so source chaos and audit pressure stop breaking the model?

The “methods” differ mostly in which job they optimize first.

At the highest level, every analytical data platform is trying to do three jobs:

1. Capture what happened (reliably and repeatably).
2. Integrate it into shared meaning (so “customer” isn’t five different creatures).
3. Serve it to humans and machines (fast, consistent, explainable).

If you only remember one thing, make it this:

These are not three competing “database shapes.”
They’re three different answers to: “Where do we put integration, and when do we pay for it?”

That’s why the debates get heated: teams are arguing about when to do hard work, not whether the hard work exists.

Before arguing about modeling philosophy, you need to understand the reality you're dealing with. That's what we invented TalkingSchema for, to explore the mess - which system owns customer identity, which system owns money, which table lies by omission, and where the business keeps asking questions the source systems were never designed to answer.

I’ll show you what that looks like, not from a whiteboard in a vacuum, but from source systems outward.

The source-system reality I start with​

Here’s the source schema I mapped in TalkingSchema before touching any architectural decision. I recommend spending a moment with the ERD, and read the DBML notes. Understand the actual mess we’re designing for.

Imagine I'm building analytics for a mid-market commerce company. Nothing exotic. Just enough complexity to hurt.

Customer identity lives in crm.customers. Orders live in sales.orders and sales.order_items. Payments live in billing.payments. Shipments live in fulfillment.shipments. Inventory snapshots live in inventory.stock_snapshots. Marketing insists promo logic matters, so now we also have marketing.promotions and marketing.order_promotions.

Source schema​

This is where methodology debates should begin: with the actual systems. Not with the end-state diagram people want to show at a meetup.

Three methodologies, one same reality​

Now comes the part people usually overcomplicate.

We're still modeling the same business. Customers buy products. Orders create revenue. Payments settle money. Shipments move goods. Inventory changes over time.

What changes is which question I optimize first.

Kimball: “Make the business question easy”​

Inmon: “Integrate the enterprise before you decorate it”​

Data Vault 2.0: “Assume change is the normal state”​

Let's dive deep on each;

Public threads solve this with a shareable link to a read-only, interactive version of your schema — no account, no installation, no friction.

What is a public thread?​

Every thread in TalkingSchema has a canonical URL. By default, that URL requires authentication. When you make a thread public, it becomes accessible to anyone with the link — fully rendered, pannable, zoomable, and readable.

Viewers can:

• Browse the entire ERD on the canvas
• Click into any table to see its fields, types, and constraints
• Follow relationship lines between tables
• See enum definitions

Viewers cannot make any changes. The schema is read-only. There's no "edit" button, no chat input, no way to accidentally modify anything.

How to create a public link​

1. Open any thread in TalkingSchema
2. Click the Share button in the top toolbar
3. Toggle Public access on
4. Copy the generated URL

The link looks like:

https://talkingschema.ai/public/{thread-id}

You can share it anywhere — a Slack message, a Notion page, a GitHub issue, a product spec. Anyone who opens it sees the current state of the schema.

Embedding a schema in a page​

Public threads also work as iframe embeds. This is useful for documentation pages, blog posts (like this one!), or internal wikis where you want the schema visible in context.

Here's an example of a live, embedded public thread — an e-commerce schema with orders, products, customers, and inventory tracking:

To embed in your own MDX or HTML:

<iframe
  src="https://talkingschema.ai/public/{your-thread-id}"
  width="100%"
  height="640"
  style="border: none; border-radius: 12px;"
  title="Schema diagram"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-popups-to-escape-sandbox"
  allowfullscreen
></iframe>

Good uses for public schema links​

In pull requests — link the relevant schema thread so reviewers can see the data model without having to read migration files. They can click through relationships, check foreign keys, and confirm field types all from the PR page.

In architecture docs — embed the schema directly in your Notion, Confluence, or internal wiki page. The schema stays live; you don't need to update a screenshot every time a table changes.

In onboarding materials — new engineers can explore the schema at their own pace. Tables are clickable, relationships are visual, and there's no risk of accidentally changing anything.

With external stakeholders — designers, product managers, and clients can understand the data model without needing to learn SQL or get access to your database.

Privacy and access control​

A few things worth knowing:

• Public links can be revoked at any time — toggle public access off and the link immediately stops working
• The link doesn't expose your conversation history or any agent context, only the schema itself
• Public threads are indexed by URL but not by any search engine or directory (no SEO crawling)

Public threads and shareable links are available on all plans. To try it, open any thread and hit Share.

TalkingSchema takes a different approach. The schema is defined once. Any export format is generated from that single source of truth, on demand, without touching the original.

The ten formats​

Here's a quick reference for when you'd reach for each one:

Same schema, different outputs​

Here's a minimal example — a users table with an email and a created_at field — rendered in four different formats to show what the same model looks like across contexts.

PostgreSQL:

CREATE TABLE users (
  id         BIGSERIAL PRIMARY KEY,
  email      TEXT NOT NULL UNIQUE,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Prisma:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  createdAt DateTime @default(now())

  @@map("users")
}

Drizzle:

import { pgTable, bigserial, text, timestamp } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: bigserial("id", { mode: "number" }).primaryKey(),
  email: text("email").notNull().unique(),
  createdAt: timestamp("created_at", { withTimezone: true })
    .notNull()
    .defaultNow(),
});

TypeScript + Zod:

import { z } from "zod";

export const UserSchema = z.object({
  id: z.number().int().positive(),
  email: z.string().email(),
  createdAt: z.coerce.date(),
});

export type User = z.infer<typeof UserSchema>;

DBML: the shareable format​

DBML (Database Markup Language) deserves a special mention. Unlike SQL dialects, DBML is designed to be readable by non-engineers — you can paste it into a doc, a PR description, or a Slack message and it reads naturally:

Table users {
  id         bigint     [pk, increment]
  email      text       [not null, unique]
  created_at timestamptz [not null, default: `now()`]
}

Table orders {
  id         bigint [pk, increment]
  user_id    bigint [not null, ref: > users.id]
  total_cents int   [not null]
  status     text   [not null, default: 'pending']
}

The ref: > users.id notation makes the relationship direction explicit at a glance. DBML is also the format TalkingSchema uses internally — which means it's always up to date with whatever you've built in the canvas.

When to export​

There's no single right time to export. A few common workflows:

• Start of a project: Design in TalkingSchema, export SQL to seed your migration tool.
• During a review: Export DBML to include in your PR description for reviewers who don't want to open a diagram.
• Onboarding a new service: Export Prisma or Drizzle to bootstrap a new TypeScript service against an existing schema.
• API documentation: Export OpenAPI to generate server stubs or client SDKs.
• Frontend validation: Export TypeScript + Zod to keep form validation aligned with your database constraints.

The key property is that any export reflects the current state of the schema — not a stale snapshot from six months ago.

All export formats are available from the Export button on any thread. If there's a format you need that isn't here yet, let us know.

These are five patterns that appear in almost every non-trivial system, with notes on when to reach for each one.

1. Polymorphic associations (done right)​

The naive version of polymorphism — a commentable_type + commentable_id column pair — works until you need a foreign key or an index. Instead, use a union table:

-- Each commentable entity gets its own join table
CREATE TABLE post_comments (
  id         BIGSERIAL PRIMARY KEY,
  post_id    BIGINT NOT NULL REFERENCES posts(id) ON DELETE CASCADE,
  comment_id BIGINT NOT NULL REFERENCES comments(id) ON DELETE CASCADE,
  UNIQUE (post_id, comment_id)
);

CREATE TABLE photo_comments (
  id         BIGSERIAL PRIMARY KEY,
  photo_id   BIGINT NOT NULL REFERENCES photos(id) ON DELETE CASCADE,
  comment_id BIGINT NOT NULL REFERENCES comments(id) ON DELETE CASCADE,
  UNIQUE (photo_id, comment_id)
);

You get real referential integrity, proper indexes, and queries that the query planner can reason about. The cost is more tables — which is almost always worth it.

2. Hierarchical data with closure tables​

Self-referential parent_id columns are easy to write and brutal to query. Getting all descendants of a node requires a recursive CTE or application-level recursion. The closure table pattern pre-computes every ancestor-descendant relationship:

CREATE TABLE categories (
  id   BIGSERIAL PRIMARY KEY,
  name TEXT NOT NULL
);

-- Every (ancestor, descendant) pair, including self-references (depth = 0)
CREATE TABLE category_tree (
  ancestor_id   BIGINT NOT NULL REFERENCES categories(id),
  descendant_id BIGINT NOT NULL REFERENCES categories(id),
  depth         INT NOT NULL DEFAULT 0,
  PRIMARY KEY (ancestor_id, descendant_id)
);

Getting all descendants of category 42 becomes a simple join:

SELECT c.*
FROM categories c
JOIN category_tree t ON c.id = t.descendant_id
WHERE t.ancestor_id = 42 AND t.depth > 0;

The trade-off: writes are more expensive (you insert N rows per new node, where N is the depth of the tree), but reads are O(1) regardless of tree depth.

3. Audit logs with event sourcing​

Instead of updating rows in place, append only and reconstruct state from history. This is particularly useful for financial systems, compliance requirements, or anything where you need to ask "what did this look like on March 3rd?"

CREATE TABLE account_events (
  id           BIGSERIAL PRIMARY KEY,
  account_id   BIGINT    NOT NULL REFERENCES accounts(id),
  event_type   TEXT      NOT NULL, -- 'created', 'credited', 'debited', 'closed'
  amount_cents BIGINT,             -- NULL for non-monetary events
  occurred_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  metadata     JSONB
);

-- Current balance is a derived value, not stored
CREATE VIEW account_balances AS
SELECT
  account_id,
  SUM(CASE event_type
    WHEN 'credited' THEN amount_cents
    WHEN 'debited'  THEN -amount_cents
    ELSE 0
  END) AS balance_cents
FROM account_events
GROUP BY account_id;

The event log is the source of truth. The balance is a projection. You can replay history, add new projections later, and audit every state transition for free.

4. Soft deletes with deleted_at​

Rather than DELETEing rows, set a deleted_at timestamp. Queries filter it out; the data stays recoverable.

The catch with soft deletes is that every query must include the filter — easy to forget, especially in ORM-generated queries. A database view or row-level security policy can enforce it:

-- All queries against this view automatically exclude soft-deleted rows
CREATE VIEW active_users AS
SELECT * FROM users WHERE deleted_at IS NULL;

Reserve soft deletes for entities that users expect to be recoverable (posts, documents, records). Don't use them for join tables or events — those should be hard deleted or append-only, respectively.

5. Slowly changing dimensions (SCD Type 2)​

When historical accuracy matters — for analytics, audits, or reporting — you need to track how data changed over time, not just what it is now. Type 2 SCDs do this by adding validity windows to every version of a record:

CREATE TABLE product_prices (
  id           BIGSERIAL PRIMARY KEY,
  product_id   BIGINT NOT NULL REFERENCES products(id),
  price_cents  INT    NOT NULL,
  currency     CHAR(3) NOT NULL DEFAULT 'USD',
  valid_from   DATE   NOT NULL,
  valid_until  DATE,                    -- NULL means "current"
  is_current   BOOLEAN NOT NULL DEFAULT TRUE,
  CONSTRAINT one_current_price_per_product
    EXCLUDE USING GIST (product_id WITH =) WHERE (is_current = TRUE)
);

To find the price on a specific date:

SELECT price_cents
FROM product_prices
WHERE product_id = $1
  AND valid_from <= $2
  AND (valid_until IS NULL OR valid_until > $2);

The EXCLUDE USING GIST constraint ensures only one price is marked is_current per product, enforced at the database level.

A note on schema evolution​

These patterns are a starting point, not a destination. Real schemas evolve — columns get added, tables split, constraints tighten. The patterns above are designed to make evolution safer: append-only events don't need migrations; closure tables can be rebuilt; SCD rows are never updated, only closed.

If you're designing a new schema from scratch, try describing the domain in plain language first. What are the things? What are the relationships? What constraints are always true? The code follows from the answers — not the other way around.

TalkingSchema is built on a different premise: you should be able to describe your data model the way you'd explain it to a colleague, and get a working, exportable schema out the other side.

The gap between thinking and building​

When you're designing a schema for a new feature, you usually start with something like:

"We need to track orders. Each order belongs to a customer and can have multiple line items. Each line item references a product, and products belong to categories."

That's a perfectly clear data model. But turning it into SQL requires a mental translation step — mapping nouns to tables, relationships to foreign keys, constraints to CHECK clauses. The design work is done in English; the implementation happens in a different language entirely.

This translation tax is low for experienced engineers, but it compounds across iterations. Every time requirements change, you re-enter DDL, re-sync your diagram, and hope nothing drifts.

What changes with a conversational approach​

With TalkingSchema, the description is the schema. You type the same sentence you'd say to a colleague and the tool:

1. Creates the tables (orders, customers, line_items, products, categories)
2. Infers the relationships (foreign keys with correct cardinality)
3. Suggests field types based on context
4. Draws the ERD — live, as you go

The result is visible immediately on the canvas. You can zoom in, click any table to edit it, rename fields, add constraints, or keep prompting in plain language.

User: Add a discount field to line_items. It should be a percentage, nullable, max 100.

TalkingSchema: Added `discount` (DECIMAL(5,2), nullable, CHECK discount <= 100) to line_items.

Two modes for two kinds of thinking​

Not every schema is the output of a single conversation. Sometimes you want the AI to make changes instantly — and sometimes you want to review a plan before anything gets applied.

Draw mode applies changes directly as you describe them. It's fast, good for exploration, and ideal when you know roughly what you want.

Plan mode lets the AI propose a set of changes for your review before anything is committed to the schema. It's better for complex restructures where you want to understand the impact before saying yes.

Both modes output the same schema — the difference is whether changes land immediately or after your approval.

The schema stays portable​

At any point, you can export the full schema to SQL (PostgreSQL, MySQL, SQLite, and others), Prisma, Drizzle, DBML, JSON, OpenAPI, and more. The AI conversation is the input — your preferred format is the output.

"The database schema is the single most important artifact in any software project. Getting it right early — and being able to iterate quickly — changes everything downstream."

This is what we're optimizing for: making the iteration loop fast enough that getting the schema right early is actually possible.

Getting started​

If you haven't tried it yet, the quickest way in is to open a new thread and describe your first table in plain English. You don't need to install anything — it runs entirely in the browser.

• Quick Start guide
• How Draw mode works
• Prompting tips for better results