How do One Big Table and AI fit together

One Big Table vs Dimensional modeling in the era of AI

Data modeling is one of the few skills left for data engineers. Context engineering is starting to dominate.

A proper data model for AI is the difference between:

• Consistent correct answers and hallucinations

• Low-latency answers and waiting forever

• Maxing out your token limit in a day and being able to use a cheaper model

In this article, we will go over how data modeling is changing in the age of AI and what you need to know

• How data engineers are drifting toward a new role: context engineers

• One Big Table vs Dimensional Modeling vs Data Vault vs AI-native Modeling

  • Each of these techniques has tradeoffs, and some work better than others for AI

The Rise of the Context Engineer

Data engineering is not about Spark and Airflow like it was in 2020. The roles that maintain pipelines and optimize queries are starting to slow down. (Although getting into Data Engineering in 2026 is still very possible)

Companies will start realizing that data engineers can do so much more. AI allows a shift from analytics-oriented architecture to action-oriented architectures.

Analysts are the bottleneck in the current architecture. In the future, data engineers will provide real-time context to LLMs, enabling much more rapid decision-making!

Enabling action-oriented architectures will be the main duty of data engineers in the coming age. This means they need to be:

• More deeply connected to the business since decisions happen fast. They need to take on both the analyst and data engineer roles to keep up!

• More well-versed with concepts like Change Data capture and Kafka streams, because data will come to LLMs faster

• Well-versed in handling unstructured data because documents are often critical in the decision-making processes of LLMs!

• They need to sharpen their system design skills to handle the three Vs of big data: velocity, variety, and volume!

All of this will allow for AI to have all the right context at the right time to make genuinely real-time decisions for the business!

Since this is more than just data, the more accurate title is:

Context Engineer

One Big Table (OBT) vs Dimensional Modeling vs AI-native Modeling

Getting the right context for your AI is complicated because:

• Too little context and your AI will make stuff up

• Too much context and your AI will get confused and burn your token budget

• You truly need the Goldilocks zone of context to maximize your ROI from AI

One Big Table (OBT) is the newest kid on the block. It puts all your columns into a single table. This feels kind of insane, but it has quite a few benefits too.

• AI really struggles with generating JOINs between tables, as is done in dimensional data modeling. This allows OBT to shine because getting the context is usually a simple WHERE clause without complex SQL generation. (As much as Databricks likes to lie to us, text-to-SQL models are still pretty bad)

• OBT’s biggest strength is also its biggest weakness. You get ALL the context. Not just the RELEVANT context.

Dimensional Modeling (also called Kimball data modeling) is the “old reliable” version of data warehouse modeling.

• Dimensional modeling’s strengths are OBT’s weaknesses and vice versa. Dimensional modeling allows you to get THE RIGHT context. But often relies too heavily on text-to-SQL to get it right.

• If you want your dimensional models to be more AI-effective, you need to:

  • Properly model your columns

    • Dimension columns are labeled as such (e.g., dim_name)

    • Fact/measure columns are labeled as such (e.g., m_revenue)

    • Column comments and table comments were rarely used by data engineers before 2023. Now they are CRITICAL for text-to-SQL models for generating and reasoning about the right values to give to the AI.

The real question is: can we have a modeling technique that gives us the retrieval simplicity of One Big Table with the “just the right amount of context” of dimensional modeling?

Enter: AI-native modeling, the question-first orientation

We will see one more layer in the ETL processes that will allow AI to have “the right amount” of context

AI thrives on the right context at the right time.

Context engineers who summarize and create data marts on top of OBT models will succeed for many reasons.

• AI thrives at mapping “question” → “appropriate data set.”

  • “What has happened with churn recently?” cleanly maps the dataset “customer_churn_detail.”

  • “Who recently bought our product” cleanly maps to the dataset “customer_purchase_detail.”

These new AI-native aggregations will help dramatically reduce token cost by processing this context with normal tools like Spark and BigQuery.

Remember, always use the right tool for the right job. This applies to data modeling as well! Both dimensional modeling and OBT are wrong in the age of AI. But they both support the downstream models very well!

What hits the spot in this article? How will you change your data modeling from here? Are you excited to be a context engineer in the future?

In the next edition of the DataExpert.io blog, we will cover unstructured data and how it fits into all of this with embeddings and RAG retrieval!

At DataExpert.io, you can get an OpenAI key, an Anthropic Key, a production Databricks account, and a production Snowflake account to build the portfolio project of your dreams for just $97/month!