Most teams do not pick a data platform for AI from a blank slate. They inherit a warehouse built for dashboards, a pile of files in object storage, and a few notebooks that quietly became production. The architecture question is really about which of those pieces to keep, which to connect, and which to replace so that training, evaluation, and serving can all draw from data you trust.

Start With the Workloads, Not the Brand Names

An AI platform serves several very different access patterns, and a design that is excellent at one can be awkward at another.

• Large sequential reads for training and fine-tuning, where throughput matters more than latency.
• Interactive analytical queries for exploration, labeling review, and evaluation analysis.
• Low-latency point lookups for online features and retrieval at inference time.
• Unstructured data handling for documents, images, audio, and logs that do not fit neatly into rows and columns.

Write down which of these you actually have today and which you expect within a year. A team that only trains tabular models weekly has very different needs from one serving retrieval-augmented generation to users in real time.

The Three Common Shapes

Warehouse-centric

A managed analytical warehouse holds curated, structured data, and ML work reads from it. This is productive when most of your signal is already tabular and your analysts and ML engineers share the same definitions. The strain shows up with unstructured data and with large training reads that are costly or slow to pull through a SQL interface.

Lakehouse

Open table formats sit on object storage, with query engines and ML frameworks reading the same underlying files. You get one copy of the data, schema enforcement, and time travel for reproducing a training set. The trade-off is operational: you own more decisions about compaction, catalogs, and engine choice.

Object store plus purpose-built engines

Raw and processed files live in object storage, and separate engines handle batch processing, streaming, feature serving, and vector search. This is flexible and avoids lock-in to a single query layer, but integration, metadata, and consistency become your responsibility.

A Comparison Table

Factor	Warehouse-centric	Lakehouse	Object store plus engines
Structured data fit	Strong	Strong	Depends on engines chosen
Unstructured data fit	Limited	Good	Good
Operational burden	Lower	Moderate	Highest
Reproducible training sets	Possible with snapshots	Natural with table versions	You must build it
Flexibility to swap tools	Lower	Moderate	Highest

Treat this as a framing device. Exact capabilities vary by vendor and change often, so check each vendor’s current documentation before relying on a specific feature.

Questions That Usually Decide It

1. Where does your data already live? Moving large datasets is slow, expensive, and risky. Gravity is a legitimate reason to pick an architecture.
2. Who operates it? A small team with no dedicated platform engineers should bias toward managed services and fewer moving parts.
3. How much of your data is unstructured? If documents and media dominate, an architecture that treats files as first-class citizens will save you workarounds.
4. What reproducibility do you need? If auditors or customers may ask which data trained a given model, versioned tables or immutable snapshots are not optional.
5. What are your latency targets for serving? Online lookups usually need a separate low-latency store regardless of what your analytical layer looks like.

A Hypothetical Example

Consider a team of six that maintains a recommendation model and is adding a document question-answering assistant. Their tabular events sit in a warehouse, and their support documents sit in a shared drive. Rather than rebuilding everything, they keep the warehouse for curated tabular data, land the documents in object storage with a simple metadata table, and add a vector index for retrieval. They defer a full lakehouse migration until the unstructured data volume justifies the added operational work. The decision is deliberately incremental, and each piece can be replaced later because the data stays in open formats.

Common Mistakes

• Choosing for the demo. A platform that makes a prototype easy may not hold up when you need lineage, access control, and repeatable pipelines.
• Ignoring egress and movement. Architectures that shuffle data between systems repeatedly create hidden cost and latency.
• Skipping the catalog. Without a shared catalog and clear ownership, even a well-chosen platform turns into a swamp.
• Over-building for scale you do not have. Distributed complexity is a cost; adopt it when a measured limit forces you to.

How to Run the Evaluation

Pick two or three candidate shapes and test them against one real workload, not a synthetic benchmark. Take a representative training dataset, a typical exploratory query, and a retrieval or lookup path. Record how long setup took, what broke, who needed to be involved, and how hard it was to reproduce a prior result. Qualitative notes from this exercise are often more informative than raw speed, because the long-term cost of a platform is mostly operational friction.

Frequently Asked Questions

Do I need a lakehouse to do AI well? No. Many teams succeed with a warehouse plus object storage. A lakehouse becomes attractive when you want one governed copy of structured and unstructured data and strong reproducibility.

Can I mix architectures? Yes, and most real systems do. The key is to keep data in open formats and maintain a single catalog so that mixing does not turn into duplication and drift.

Where should the vector index live? It depends on scale and latency needs. Some teams use an extension in an existing database, others use a dedicated vector store. Evaluate it against your retrieval workload rather than treating it as part of the core platform choice.

How important is the choice of file or table format? Quite important for portability. Open, widely supported formats make it easier to change engines later, which reduces the risk of any single platform decision.

How often should we revisit the architecture? Review it when your workloads change meaningfully, such as adding real-time serving or a large unstructured corpus, rather than on a fixed calendar.

Next Step

List your current workloads and data locations on one page, mark which pattern each one needs, and choose a single real workload to test against your top two architecture candidates this month.