Data Architecture: The Foundation for AI in Your Org

About this article

This article is the first article in the “Data Architecture” category of the Architecture Crash Course for the Generative-AI Era series. It covers the big picture of data architecture.

In 2026, “we want our data trained into AI” has become a default executive request, and whether your data is set up to be handled across systems is being re-evaluated as the precondition for AI utilization. This article surveys OLTP/OLAP separation, the data flow, datastore choices, and the structural fact that the quality of your data architecture sets the upper limit of AI utilization.

A full list of all articles in this category, with summaries and learning points, is available at the following page.

Data Architecture — Article Indexen.senkohome.com/arch-intro-index-data/

What is data architecture

Think of a company’s vault and ledger. Cash (operational data) is stored securely, while the ledger (analytical data) reveals the state of the business. Both deal with the same “money,” yet how they’re stored and how they’re used are completely different. Mix the two and both daily transactions and financial reporting slow down.

Data architecture is the discipline of designing where data lives, in what format, and how it flows between stores. It covers the separation of operational (OLTP) and analytical (OLAP) systems, datastore selection, and data-flow design.

Without data architecture, data gets siloed per system, making cross-organizational analytics and AI utilization impossible.

Why it is treated as an architecture of its own

There are three reasons. First, operational and analytical workloads want fundamentally different things. Operational systems want “one transaction, fast and safely”; analytical systems want “aggregate and analyse large volumes” — try to satisfy both on one database and both get slower. Second, data crosses the organisation. Hold customer and product data in a different shape in every system and company-wide analysis becomes impossible. Third, the value of data is decided by accumulation. An application can be rebuilt; past data can never be obtained again. A sloppy initial design leaves you, five years later, wanting to use your data and finding nothing usable there.

The main kinds of data, and how they flow

Each data type has different optimal storage and processing, so trying to handle all of it in one DB breaks down.

The flow from operational systems through an analytics platform to BI tools and ML has converged on roughly this pattern:

Data lake = “a place to dump raw data.” DWH = “a DB shaped for analysis.” ETL/ELT (Extract / Transform / Load) = “the moving and reshaping machinery.” Memorizing those framings is step one.

How to choose — a ladder by data volume and freshness

Note: industry rates as of April 2026. Periodic refresh required.

In data architecture the optimal answer is determined by volume and freshness requirements. Up front: PostgreSQL alone is enough up to ~1 TB. At 10 TB, separate the DWH. Lakehouse and streaming become realistic only past 100 TB.

“Real-time streaming costs ~10x to operate” is the rule of thumb. 90% of business needs are met by daily batch. When you hear “real-time”, question it first — micro-batching (15-min cycles) is enough for most cases.

Data architecture evolves in stages with scale and freshness. Aiming at real-time from day one is over-investment.

Knowledge structure of this category

This category is composed of 7 articles in total. The structure follows store -> structure -> move -> govern, learning how to handle data step by step.

Store first selects where data lives (RDB, KVS, columnar, vector DB, etc.). Getting this wrong ripples through everything downstream.

Structure designs table schemas (normalization, star, etc.) and separates operational vs analytical platforms (DWH, data lake) on top of the chosen store.

Move designs how to transport structured data from operational DBs to the analytics platform. For most projects batch (ETL/ELT) is enough; streaming enters the picture only when real-time freshness is required.

Govern — data governance — is a cross-cutting theme covering catalog maintenance, quality management, and access-control design. In the AI era, metadata maintenance is a precondition for AI utilization, so it’s worth starting early rather than deferring.

AI decision axes — How tidy your data is sets the ceiling on AI use

Vector DB and RAG have become a new layer of data architecture

In products that leverage LLMs, a RAG pipeline — vectorizing internal documents and past Q&As for retrieval to improve LLM answer accuracy — is becoming a standard configuration. Alongside traditional RDB + object storage, vector DBs (pgvector, Pinecone, Weaviate) are establishing themselves as the third layer of data architecture.

Explicit schemas are the precondition for Text-to-SQL

To have AI generate SQL from natural-language questions like “show last month’s top 10 by revenue,” the table schemas, column meanings, and inter-table relationships must be explicit as metadata. With schemaless JSON storage or tables with unclear naming, AI cannot generate accurate SQL.

Pitfalls and forbidden moves

Of the forbidden moves covered in detail across the individual articles, here are the six that matter at the level of the whole.

Author’s note — “stored, but not usable” cases

There’s a recurring story: a site decided to “just dump JSON event logs and analyze later” for years, only to find at use time that “field names differ between versions, timezones depend on the device and are inconsistent, and rows with missing keys flood the dataset” — almost no records were re-processable. The accumulation succeeded, but they hadn’t accumulated it in a usable form.

Another case: an operational DB and analytics ran on the same PostgreSQL, and every nightly batch dragged daytime order processing. The fix was bolting on a DWH after the fact, then spending six months in dual-maintenance mode. Effort that wouldn’t have been spent if OLTP and OLAP had been separate from day one.

I personally watched a single-PostgreSQL setup running both BI dashboards and daily aggregation slow the entire service down on monthly-batch days. The root cause is “accumulating with the wrong tool/structure for the data’s character.” Design-time decisions determine your utilization runway five years later — these are visible-from-outside cases of that fact.

Data, unlike applications, cannot be rebuilt. Design as a 5-year asset.

What to decide — what is your project’s answer?

For each of the following, try to articulate your project’s answer in one or two sentences. Each is covered in detail in the individual articles beneath this one.

• The operational database (PostgreSQL, MySQL and the like) and the analytical warehouse (BigQuery, Snowflake and the like)
• Whether you need a data lake (S3 and the like)
• Whether you need ETL / ELT tooling and a streaming platform
• The data-modelling approach (3NF or star schema)
• Whether you need a vector database (pgvector, Pinecone)
• How the data catalogue and access permissions are managed

Summary

This article covered the big picture of data architecture — OLTP/OLAP separation, the per-type storage map, the volume × freshness ladder, and AI-era standard equipment.

Separate operational from analytical, make schemas and types explicit, match tools to data types, and design as a 5-year asset. The realistic answer for 2026.

The next article covers datastore selection (when to use RDB / KVS / columnar / vector DB / etc.).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.