--- title: Data Modeling for AI Applications: Designing Databases... description: Building AI applications requires rethinking database design beyond traditional entities like Users and Orders. Production AI systems need explicit models for... canonical: https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Data Modeling for AI Applications: Designing Databases Beyond Users and Orders | daily.dev og:description: Building AI applications requires rethinking database design beyond traditional entities like Users and Orders. Production AI systems need explicit models for... og:url: https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj og:image: https://api.daily.dev/og/posts/JJtpA8frj.png og:image:alt: Data Modeling for AI Applications: Designing Databases Beyond Users and Orders og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Data Modeling for AI Applications: Designing Databases Beyond Users and Orders **[Medium](https://daily.dev/sources/medium_js)** · 5 min read · 0 upvotes · 0 comments ## Summary Building AI applications requires rethinking database design beyond traditional entities like Users and Orders. Production AI systems need explicit models for Conversations, Messages, Documents, Chunks, Embeddings, Prompts, and AI Usage tracking. Key principles covered include separating conversations from messages for analytics, splitting documents into chunks for better retrieval, storing metadata alongside vectors for filtered search, versioning prompts like code to enable A/B testing and rollback, and tracking token usage and costs per model. Common mistakes include storing conversations as JSON blobs, ignoring prompt version history, and designing schemas tied to a single model provider. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How should I structure a database schema for a chatbot's conversation history instead of storing it as one JSON blob? Separate conversations from messages into two tables: a Conversation table with id, user_id, and created_at, and a Message table with id, conversation_id, role, content, and created_at. This structure supports easier searching, better analytics, conversation replay, and pagination, compared to storing an entire conversation as a single JSON column which becomes hard to query as it grows. _For teams designing chatbot schemas, daily.dev surfaces practical data modeling approaches like this one._ ### Why should I split documents into chunks and embeddings instead of storing a document with a single embedding? Retrieval systems rarely need an entire document, so splitting into chunks improves search accuracy, response quality, and token efficiency. A recommended model uses three tables: Document (id, title, source), Chunk (id, document_id, content, chunk_number), and Embedding (id, chunk_id, vector, model_name), so a query can retrieve just the relevant paragraph rather than an entire handbook. _Anyone building RAG pipelines can find similar chunking and embedding schema patterns on daily.dev._ ### Why do AI applications need to version their prompts like code? Storing prompts only as hardcoded strings in application code makes it impossible to answer which prompt generated a given response, whether a new prompt improved results, or whether yesterday's output can be reproduced. A versioned Prompt table with id, name, version, template, and created_at enables A/B testing, rollback, experimentation, and auditing of prompt changes over time. _Developers tracking prompt changes across releases can follow related AI engineering practices on daily.dev._ ## Similar posts on daily.dev - [Designing the agent-ready data stack](https://daily.dev/posts/designing-the-agent-ready-data-stack-hb3dcwedk) · InfoWorld · 0 upvotes · 0 comments - [Why the secret to scaling AI isn’t a better model, it’s a simpler foundation](https://daily.dev/posts/why-the-secret-to-scaling-ai-isn-t-a-better-model-it-s-a-simpler-foundation-xepzjzznp) · The New Stack · 1 upvotes · 0 comments - [Why Building AI Products Is More Than Connecting an API](https://daily.dev/posts/why-building-ai-products-is-more-than-connecting-an-api-1ojnpkkur) · SitePoint · 0 upvotes · 0 comments --- Tags: [#ai](https://daily.dev/tags/ai), [#backend](https://daily.dev/tags/backend), [#rag](https://daily.dev/tags/rag), [#vector-search](https://daily.dev/tags/vector-search) [View this post on daily.dev](https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Data Modeling for AI Applications: Designing Databases Beyond Users and Orders","url":"https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj"},"datePublished":"2026-07-21T05:32:25.337Z","dateModified":"2026-09-13T20:41:39.347Z","description":"Building AI applications requires rethinking database design beyond traditional entities like Users and Orders. Production AI systems need explicit models for...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"ai,backend,rag,vector-search","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Data Modeling for AI Applications: Designing Databases Beyond Users and Orders"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/data-modeling-for-ai-applications-designing-databases-beyond-users-and-orders-jjtpa8frj#faq","mainEntity":[{"@type":"Question","name":"How should I structure a database schema for a chatbot's conversation history instead of storing it as one JSON blob?","acceptedAnswer":{"@type":"Answer","text":"Separate conversations from messages into two tables: a Conversation table with id, user_id, and created_at, and a Message table with id, conversation_id, role, content, and created_at. This structure supports easier searching, better analytics, conversation replay, and pagination, compared to storing an entire conversation as a single JSON column which becomes hard to query as it grows. For teams designing chatbot schemas, daily.dev surfaces practical data modeling approaches like this one."}},{"@type":"Question","name":"Why should I split documents into chunks and embeddings instead of storing a document with a single embedding?","acceptedAnswer":{"@type":"Answer","text":"Retrieval systems rarely need an entire document, so splitting into chunks improves search accuracy, response quality, and token efficiency. A recommended model uses three tables: Document (id, title, source), Chunk (id, document_id, content, chunk_number), and Embedding (id, chunk_id, vector, model_name), so a query can retrieve just the relevant paragraph rather than an entire handbook. Anyone building RAG pipelines can find similar chunking and embedding schema patterns on daily.dev."}},{"@type":"Question","name":"Why do AI applications need to version their prompts like code?","acceptedAnswer":{"@type":"Answer","text":"Storing prompts only as hardcoded strings in application code makes it impossible to answer which prompt generated a given response, whether a new prompt improved results, or whether yesterday's output can be reproduced. A versioned Prompt table with id, name, version, template, and created_at enables A/B testing, rollback, experimentation, and auditing of prompt changes over time. Developers tracking prompt changes across releases can follow related AI engineering practices on daily.dev."}}]} ```