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.
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_itemsOutbound 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.
| Path | For | Lands in |
|---|---|---|
| Database source | upstream systems with JDBC | iceberg.<your schema> |
| CSV import | extracts, lists, master data | iceberg.<your schema> |
| Documents | PDF, Word, text | iceberg.documents |
| Fileshare crawler | whole directories | iceberg.crawl, iceberg.crawl_docs |
| MCP ingestion | systems with an MCP server | iceberg.<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