Skip to content
MCP server built inHow that works
Back to the platform overview

Getting data in

Four ways into the lakehouse — each with an assistant

Ingestion is where lakehouse projects stall: somebody has to get the data in, and usually that somebody is a script one person understands. lavalake turns it into four paths in the console that all end in the same open format.

Databases
PostgreSQL, MySQL, MS SQL Server
Files
CSV with a modeling assistant
Documents
PDF, Word, text
Target
Apache Iceberg

Databases as a source

A source is registered in the console: type, host, database, credentials. Credentials are stored AES-256-GCM encrypted, access is read-only, and TLS can be enforced per source rather than globally. You then pick the tables to bring over as Iceberg.

Console · Data sources
Type        postgres | mysql | mssql
Host        erp-db.dc.internal:5432
Database    sales
Login       reader / ********     (stored encrypted)
TLS         enforced

Bring over
  sales.public.orders     ->  lakehouse.raw.orders
  sales.public.line_items ->  lakehouse.raw.line_items

Outbound access is not unrestricted: an egress guard stops a registered address from pointing at internal metadata endpoints or into other network segments. A data source is user input, and user input gets checked.

  • Three database types: PostgreSQL, MySQL, MS SQL Server
  • Read-only access, credentials encrypted
  • TLS enforceable per source
  • Change data capture and continuous ingestionIn development

Files with a modeling assistant

Uploading a CSV is the easy part. The hard part is everything after: which column is a date, which is an amount, what does an empty field mean, and which rows are duplicates. The import assistant takes exactly those steps — detect and correct types, rename columns, declare null tokens, drop duplicates — and only then loads.

Large files report loading progress in rows, and a running import stays visible while you work on another page. That sounds minor, but it is the difference between a tool people use and one they avoid after the second timeout.

Documents become tables

This is the decision we care about most. A document is not placed in a second content store with its own access control. It is chunked, and the chunks become an ordinary Iceberg table: one row per chunk, with the text and character offsets back into the original.

Because a document becomes a table, permissions, audit and lineage apply to documents without a single extra rule.

The text column is then embedded — through the same pipeline as any other table. The vector index only remembers which columns are key and text, never the authoritative content. Search re-fetches the chunk from Trino later, under the searcher's token. Masked columns therefore stay masked in search results too.

Parsing runs in a separate process. A malformed or malicious PDF does not take down the service that manages permissions.

Fileshare crawler and MCP ingestion

Instead of uploading files one by one, the crawler points at a directory. And because MCP servers can be registered as sources, you can attach systems that have no JDBC driver but do have an MCP server — SAP through SAP-MCP, for instance.

PathForLands in
Database sourceupstream systems with JDBCiceberg.<your schema>
CSV importextracts, lists, master dataiceberg.<your schema>
DocumentsPDF, Word, texticeberg.documents
Fileshare crawlerwhole directoriesiceberg.crawl, iceberg.crawl_docs
MCP ingestionsystems with an MCP servericeberg.<your schema>

There is deliberately no enforced bronze/silver/gold layering. You pick the target schema; the convention stays yours.

See it instead of reading about it

In half an hour we walk through the platform against your questions — ingestion, permissions, search, agent. No slides.

Book a live demo