Lakebase Hackathon Learnings: When the Database Stops Being the Bottleneck
In July, we joined the Databricks Lakebase Hackathon in Zürich. Teams built working applications ranging from health-data chat interfaces and risk-management tools to marketing campaign apps and solutions supporting trading and forecasting in the energy sector.
Lakebase is Databricks’ fully managed PostgreSQL database for transactional workloads, which is built for applications that need low-latency reads and writes alongside lakehouse data.
Databricks invited ELCA to support the participants with their platform-related questions throughout the event. We helped with the practical details: setting up Lakebase connections, working through data synchronisation, and discussing how specific application features could be implemented for each use case.
To help the teams start quickly, we also prepared a Lakebase Quickstart repository (INSERT LINK HERE) before the event. Several teams used it as their starting point, reducing the setup effort and getting into their use cases faster. From there, our support shifted naturally from setup to the individual projects, their data flows and application-specific questions.
Looking back at the hackathon, three things stood out.
1. Infrastructure setup was completed before the second coffee
Hackathons usually make infrastructure friction painfully visible. Lose two or three hours to provisioning, credentials and environment setup, and a large part of the day is already gone.
Lakebase changed that starting point. The branching feature in Lakebase provides isolated, writable copies in seconds using copy-on-write storage. Idle compute can scale to zero and automatically resume within a few hundred milliseconds when it is needed again.
For a hackathon, this velocity matters. Developers can work on isolated branches, try changes without touching the main database, discard what did not work and keep moving.
Combined with our Quickstart and familiar PostgreSQL tooling, this meant database setup receded into the background. By the second coffee, the teams were working focused on their use cases rather than on their infrastructure setup.
2. The most valuable pipeline is the one you never have to build or maintain
One of the most interesting projects was a chat interface over personal health measurements.
The application combined data from Unity Catalog and Lakebase so users could ask questions about their own data. The team then extended it with Agent Bricks, using a RAG-based verification layer to validate generated answers.
This illustrates one of Lakebase’s strongest patterns. Applications frequently need governed data that already exists in the lakehouse: customer information, metrics, model outputs or reference data. Traditionally, serving that data at application latency means adding an operational database and building another pipeline to keep it current.
Lakebase synced tables shorten that path: Unity Catalog data becomes available through PostgreSQL for low-latency access, without any hand-crafted sync pipeline to build or maintain. Once that connection was in place, the teams could spend their time working efficiently on richer application features rather than on common infrastructure or basic data-entry functionality.
3. The lakehouse is becoming a place to build, not only to analyse
Having governed data available is only part of the story. The next step is turning that data into applications people actually use.
The projects we saw at the Hackathon made that shift tangible, for example:
- A risk-rule management application turned data into an operational workflow.
- An employee-reallocation tool supported warehouse operations.
- Another application combined governed metrics and lineage with a feedback workflow backed by Lakebase.
Applications also need to capture input, maintain state and trigger actions. Lakebase gives teams a transactional database directly alongside the lakehouse. This makes it easier to build operational capabilities close to the governed data that is already in place, rather than exporting analytical data to a separate application stack.
For us, this was one of the most interesting shifts of the day. The lakehouse was no longer a place where data only was analyzed. It became the foundation for applications built around that data.
Still PostgreSQL. Still engineering.
Making the infrastructure easier does not make the engineering decisions disappear. Lakebase takes a significant amount of operational work off the table, and AI-assisted development can accelerate implementation even further. But it still does not remove the need to design a proper data model.
Primary keys, indexes and access patterns still matter. So does deciding what belongs in an operational database, what should remain analytical, and how data should move between the two.
That was visible throughout the hackathon. Teams could build quickly, and when architecture or best-practice questions came up, they turned to us. This is exactly what we were there for and where ELCA adds value: combining platform expertise and engineering experience with AI-assisted development so that speed leads to the right solution, not simply a faster implementation.
Are you wondering which part of your architecture will benefit from Lakebase?
Talk to us. We can walk through your operational and analytical workloads and identify where Lakebase could simplify the architecture.