Multimodel Tables: One Table for Files, Embeddings and Hybrid Search for Agents

For years the database in question has been growing toward a single unified system, covering distributed transaction processing for critical workloads, HTAP, multi-model data and hybrid search. Its Lakebase product signals a further change in emphasis. The question is no longer only what the database can process but who it serves. Databases used to be built for developers, DBAs and applications. The vendor argues that in the AI era they must also serve a new kind of user, the agent.

On that definition, an "AI database" isn't simply one that can store images, PDFs or vectors. It's one built to hand agents complete, current and trustworthy context to reason and act on, with embeddings, raw files and hybrid search answering from the same place. The rest describes the multimodel table feature in Lakebase and the problem it goes after. These are the vendor's claims, so test them against your own workload.

The agent's data problem

Picture one agent decision. It might need a structured user profile, a text summary of the conversation, the original PDF from a knowledge base, semantic hits from vector recall and the current state of the business, all at the same time.

Today those five usually live in five systems: object storage, a search engine, a vector database, a business database and an offline warehouse. There is no shared transaction, no consistent snapshot and no common lineage.

If a PDF is updated while its embedding still points at the old version, the agent answers confidently and wrongly, and nobody knows. That isn't a matter of storing more data types. It's a governance problem. Once multimodel data sits on the critical path, someone has to guarantee version consistency, completeness of computation, traceability and trust. In many teams that someone is a pipeline they own, debug and rewrite every quarter.

The multimodel table is Lakebase's answer. It is the central data-management feature of the product and manages images, audio, video, PDFs, web snapshots, vectors, JSON and plain structured columns as proper database objects in their own right. They sit in one system that offers transactions, consistency, high availability, hybrid search, analytical computation and online serving.

Why agents need a different data model

The objects an agent deals with are multimodel by nature. Inputs range from natural language to images, PDFs, web pages, tables and business context. While running, the agent leans on user memory, knowledge bases, RAG output, structured business data, semantic profiles and intermediate model results.

Four shifts follow:

1. Unstructured data moves onto the critical path. It stops being an attachment parked in object storage and becomes a key input to decisions.
2. Access becomes hybrid search. A single request can mix structured filters, full-text retrieval, vector recall and analytical aggregation.
3. Real-time demands rise. Agents run around the clock, and next-day reporting can't keep up.
4. Features are generated dynamically. Many fields aren't written directly. Models extract them asynchronously from raw data.

The practical question becomes how to unify raw multimodel data, structured fields, derived features and asynchronous results in one database, and let them serve online transactions, analytics and hybrid search together without losing consistency or visibility. That is the design problem the multimodel table is aimed at.

Core capabilities

One home for multimodel objects

Multimodel tables place these objects under the database's own transaction and version control. Large objects such as images, audio, video, PDFs and web snapshots can be stored in several different ways. Where the bytes physically sit matters less than what the database promises about them: an ID that doesn't change, a place to reach it, a version number, a visibility status and a defined transaction scope.

This is meant to ensure that a raw object and its derived features, such as summaries, labels, embeddings and risk scores, always match the same data version. The bug where an object is updated but its features still describe the old content shouldn't occur.

Dynamic feature columns

Multimodel data is rich, and a single raw object can give rise to an endless set of features: semantic, structural, quality-related and business-specific. From text you can get topics, summaries, embeddings, safety labels, the language and a quality score. From an image come OCR output, tags, risk scores and business attributes. Every new model adds more.

Under a classic schema, each new feature means a DDL change. Each DDL change causes cache invalidation, write amplification and background compaction pressure, so the pace of feature work slows to the speed of table locks.

Multimodel tables use a lightweight dynamic-column mechanism. Adding a feature needs no schema change, queries stay SQL-native, analytical optimisation still applies and hybrid search still hits an index. This isn't a retreat to key-value storage, which is flexible but blind to SQL analysis and search optimisation. The design makes a deliberate trade between optimisable structure and dynamic extensibility, and tries to keep both.

Asynchronous, near-real-time computation

Many columns aren't written by users at all. Computation tasks generate them, including embeddings, summaries, OCR, quality scores, full-text indexes and vector indexes, using built-in model features, background jobs or external pipelines.

Model inference commonly takes hundreds of milliseconds to seconds, which is too slow to block an online write. So the table doesn't wait:

1. Raw data commits first, keeping online write latency intact.
2. Background tasks start feature extraction, index building and backfill according to lineage.
3. Derived values show up within a near-real-time window.
4. Reads always see one consistent snapshot.

The judgment behind this is that strict synchronisation of every derived column is impractical and unnecessary. A controllable balance of latency, throughput, storage efficiency and consistency is the right target. The computation tasks produce the values, and the table makes them governable, searchable, analysable and consistently readable.

Column-group consistency

Asynchronous computation introduces a visibility problem. Once a row exists, feature A, feature B, the embeddings, the full-text indexes and the quality labels can each finish at a different moment, produced by different tasks and different models. If a query sees B complete while A is still pending, it will return wrong answers without any warning.

Column-group consistency handles this in the storage layer. A business column group becomes a new visible snapshot only after every related derived column has completed. Queries and hybrid search read a consistent snapshot and never encounter half-finished data.

Separated storage and compute, with hot and cold together

Multimodel data grows without a ceiling across documents, images, video, vectors and derived features, so keeping all of it hot isn't viable at scale. These tables sit on a disaggregated architecture with shared storage and treat hot and cold as a continuum:

• Recent data, say the last 90 days, is cached on SSD so access stays fast.
• Older data, for example beyond 90 days, settles on cheaper shared storage while remaining queryable, searchable and analysable through the same interface.

Nobody has to switch systems to reach cold data, or stitch together an online database, object storage and an offline warehouse to answer a single question. There is one view, one query surface and one governance model.

Lineage and a unified catalog

Which text segment did that embedding come from? Which audit model assigned that safety label? Which version of the PDF does that summary describe?

Lineage and the unified catalog form the metadata backbone. They capture how raw objects, structured fields, dynamic feature columns, model tasks, versions and permissions relate to each other. The metadata supports three things:

1. Triggering. Background tasks for extraction, index building and backfill start automatically from lineage.
2. Completeness. Before visibility moves forward, the system checks that a column group or snapshot has been fully computed.
3. Traceability. When an agent gives an answer, you can trace it back to the documents, images, records and derived features it used.

One access layer for transactions, analytics and search

A multimodel table is described as a shared foundation for three workloads on the same data:

• online transactions, meaning business writes with ACID guarantees and high availability;
• analytics, meaning large scans, aggregations, filters, joins and feature analysis;
• hybrid search, meaning structured filters combined with full-text retrieval, vector recall, tag filtering and business ranking.

Agent access is multi-step by nature. A request may filter on structured conditions, then search descriptions as full text, then look for similar content through vector recall, then rank by tags, quality, recency and permissions. No single specialised engine covers all four steps.

The central trade-off is near-real-time over strong synchronisation. Search and analytics don't need derived features to finish inside the write transaction, but those features must become visible within a short, bounded window and be read from a consistent snapshot. That is how one table can serve online writes, hybrid retrieval and analytics without the cost of keeping three copies stitched together.

What it replaces

For an agent project today, the pitch is that it replaces a stack of object storage, a search engine, a vector database, a business database and an offline warehouse. The old compromise between multimodel breadth and database-grade governance is meant to disappear.

Why it matters

The real question isn't whether an AI database can store images, PDFs or vectors. It's what changes when agents become first-class users of the database.

If the answer is one more isolated system per data type, there's more surface to secure, more pipelines to break and more silent drift. If the answer is a single governed table where every modality is a first-class object, you get a genuine data foundation instead of scaffolding made of pipelines.

Multimodel tables bring structured data, unstructured data, AI-derived features and business semantics under a single system for transactions, governance and computation. Databases used to unify data. In the AI era they need to unify data, semantics and the operations that produce them, and this feature is Lakebase's first step in that direction.

Evaluating it

Multimodel tables ship as part of Lakebase. To judge them on your own agent workload, list the data types you must manage, the agent scenario you're building and any performance or governance requirements, then model one multimodel table and compare it against the stack it would replace. The test that counts is whether the agent stops shipping wrong answers.