how to build a full-stack app with databricks apps, lakebase, and AI
Building a full-stack app usually means making a lot of decisions before you get to the actual product.
You need somewhere to host the app. You need a database. You need authentication. You need a way to connect to data. You need a development workflow. If the app is data-heavy, you also need to think about analytics, governance, and how your application data connects back to the rest of your platform.
That is what made this recent Databricks workshop useful.
Ed Pearson, Principal Consultant and Databricks Delivery Lead at Analytics8, walked through how developers can use Databricks Apps, Lakebase, and AI coding tools to build a small full-stack application without setting up traditional infrastructure from scratch.
The demo used a simple Bakehouse Rewards app. Think of it like a lightweight restaurant or coffee shop rewards program. The app used sample Bakehouse data already available in Databricks Free Edition, created a Lakebase database to store reward redemptions, and used Genie Code to help scaffold the application.
The point was not that AI builds everything perfectly for you.
The point was more practical: developers can now move from idea to working prototype much faster when app hosting, Postgres, data access, and AI assistance live closer together.
tl;dr: what developers can learn from the databricks workshop
Databricks Apps lets developers build and deploy apps directly inside the Databricks platform.
Lakebase adds a managed Postgres layer for transactional app data.
The workshop demo built a Bakehouse Rewards app using sample Lakehouse data and a Lakebase database.
AI coding tools helped scaffold the app, but the developer still had to guide prompts, permissions, testing, and troubleshooting.
The most useful workflow is simple: start with existing data, create a small app, connect a transactional database, test the app flow, and iterate.
start with the problem: apps need more than analytics data
Databricks is usually associated with data engineering, analytics, machine learning, and lakehouse workflows.
That means software engineers may not immediately think of it as a place to build full-stack applications. Ed called that out early in the workshop. If you come from a software engineering background, Databricks may not be the first tool you reach for when you want to build an app.
But Databricks Apps changes that use case.
Databricks Apps gives developers a way to build and deploy data and AI applications directly on the Databricks platform. Instead of standing up a separate hosting layer, the app can run inside the same environment where the data already lives.
For developers, that matters because many modern applications are not just basic CRUD apps. They often need to read from analytical data, write new transactional data, connect to AI workflows, and expose a usable interface to internal users or customers.
That is also why this workflow fits into a broader developer community for people building across software, data, and AI.
The goal was not just to show that an app could run. The goal was to show how app development, data access, Postgres, and AI-assisted coding can work together in one workflow.
use databricks apps for the application layer
In the workshop, Ed described Databricks Apps as a serverless, consumption-based app platform with built-in authentication and OAuth support.
That removes some of the infrastructure work developers would normally need to handle before building the actual app. You are not starting by choosing a hosting provider, wiring up authentication, and building deployment plumbing from scratch.
You can start closer to the application itself.
For the demo, the app was called Bakehouse Rewards. The basic idea was simple: show customers, display rewards, allow a user to redeem a reward, and track those redemptions.
That simplicity is part of what made the example work. A rewards app has enough moving parts to be realistic, but not so many that the learning gets buried.
You have customer data, product or transaction data, a user-facing app, reward redemption actions, a place to write new app data, and a need to connect analytical and transactional systems.
That is a useful pattern for developers to understand because it maps to many real internal tools: admin dashboards, support tools, customer portals, data entry apps, approval flows, or lightweight AI interfaces.
It also connects well to other technical workshops where developers are learning how to move from concept to working prototype without getting stuck in setup.
use lakebase when the app needs postgres
A full-stack app usually needs a database that can handle transactions.
In this demo, that role was handled by Lakebase, Databricks’ managed Postgres database.
This is where Ed made an important distinction between OLAP and OLTP.
OLAP stands for online analytical processing. That is the analytics side: dashboards, reporting, historical queries, large datasets, and business questions.
OLTP stands for online transaction processing. That is the application side: writing records, updating state, storing transactions, and handling user actions.
The Bakehouse Rewards app used both.
The Lakehouse data handled the analytical side, such as customers and transactions from the sample Bakehouse dataset. Lakebase handled the transactional side, such as recording reward redemptions.
That split matters.
You do not want every app write to become an analytics problem. You also do not want to force a transactional database to behave like a full analytics platform. The useful part is having both layers close enough that they can work together.
For developers, Lakebase also has practical development features. Ed highlighted branching as one of the more interesting ones. If you need production-like data to test a feature, you can create a branch of the database, work against that branch, and avoid touching production data directly.
That is especially useful in AI-assisted development, where you may want to test an idea quickly, throw it away, or iterate without worrying about breaking a shared environment.
let AI scaffold the app, but do not let it drive blindly
The workshop used Genie Code, Databricks’ agentic coding experience, to help build the app in the browser.
Ed started with a prompt that explained what the app should do, what data it should use, what permissions it needed, and what counted as a successful test. The AI assistant then generated a plan, created files, worked through setup steps, and began deploying the app.
That is where the demo felt realistic.
The app did not magically become perfect on the first try. Some parts worked. Some parts needed adjustment. The tool had to work through permissions and deployment steps. At one point, the app was still running through the prompt, creating files, and handling access control issues.
That is not a failure. That is the actual lesson.
AI coding tools are useful, but they are not a replacement for clear thinking. The developer still needs to define the app, describe the data, set the acceptance criteria, review the output, and troubleshoot when something does not behave as expected.
A weak prompt would be:
“Build me a rewards app.”
A stronger prompt gives context:
What the app is called
Which sample data to use
What should be read from the Lakehouse
What should be written to Lakebase
What tables need to exist
What the user should be able to do
What a passing test should prove
That is the difference between asking AI to guess and asking AI to execute against a clear plan.
what developers can try next
The best way to learn this workflow is to build something small.
Do not start with a large production application. Start with a focused app that proves the pattern.
A good first project should answer a few basic questions:
Can the app read existing data?
Can it write new transactional data?
Can you inspect what was written to Postgres?
Can you connect app activity back to analytics?
Can you redeploy, test, and troubleshoot when something breaks?
The Bakehouse Rewards demo is a good model because it has a clean app flow. A user selects a customer, views rewards, redeems something, and the app writes that redemption somewhere.
You could apply the same pattern to other small apps: an internal data request tracker, a customer notes app, a support queue dashboard, a lightweight product feedback tool, a simple admin interface, an AI-assisted data exploration app, or a form that writes to Postgres and reports trends from Lakehouse data.
The goal is not to build something impressive on day one.
The goal is to learn how the pieces fit together.
If you are looking for more sessions like this, check out upcoming community events and workshops built for developers, technical candidates, and people learning across software, data, and AI.
make the workflow the main takeaway
The most useful part of the workshop was not just seeing Databricks Apps or Lakebase in action.
It was seeing the workflow.
Start with data that already exists. Create a small application around a real use case. Use a transactional database for writes. Use AI to speed up scaffolding. Test the app. Watch what breaks. Adjust the prompt. Keep iterating.
That is a practical model for developers who want to experiment with data-backed applications without spending most of their time on infrastructure setup.
Databricks Apps can provide the app layer. Lakebase can provide the Postgres layer. AI coding tools can help create the first version faster.
But the developer still owns the judgment.
You still need to understand the user flow, the data model, the difference between analytics and transactions, the permissions, and the definition of done.
That is the real lesson from the workshop.
AI can help you build faster, but clear technical thinking is still what makes the app useful.
If you want to keep learning with other developers, join the Randstad Digital community. You will find live workshops, technical sessions, and practical conversations with people building across software, data, and AI.
