Skip to main content

AI-First Database Design: Rethinking How We Build Data Models

· 3 min read
Karan Patel
Karan Patel
Founder, CEO
Mishall Afzal
Mishall Afzal
Co-founder, CTO

For decades, designing a database meant one of two things: writing SQL DDL by hand, or dragging boxes around a diagramming tool. Both approaches force you to think in the machine's language before you've finished thinking in your own.

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.