Postgres, inside the lakehouse
Lakebase implementation, from the schema to the application on top
When an application beside Databricks keeps its own Postgres, somebody ends up reconciling that copy with the lakehouse, usually by hand, and the governance you run in Unity Catalog stops at its edge. Lakebase is the managed serverless Postgres Databricks runs inside the lakehouse, with branching, point-in-time recovery and Unity Catalog over it.
We design the schema, wire the sync to your lakehouse tables, and build the transactional application or the agent memory that runs on it, so the app, the agents and the reports sit under the same grants, with the sync between them designed up front rather than patched when the numbers disagree.
- Who it is for
- Data and product leaders putting an operational workload on Databricks
- Bench
- 115+ engineers, 80 Databricks-certified
The database is the easy half. What Lakebase actually asks for is somebody who can build the application on top of it, which is a different trade from building pipelines and the one we started in, building custom web and mobile applications years before our Databricks bench.
What we work out first
- Which workload actually belongs in Postgres rather than in a Delta table, because the answer is not everything
- What the application needs to read at request latency, and what can wait for a sync
- Where the operational data has to reconcile with the analytical copy, and who wins when they disagree
- Whether Unity Catalog governance over the Lakebase catalog matches the grants the rest of the estate uses
- What the branching workflow should be, because a database you can branch changes how a team ships
- Whether an agent needs persistent memory here, and what it is allowed to remember
What we build
- Schema design for the transactional side, sized for the access pattern rather than for the report
- Sync between Lakebase and lakehouse tables, with the direction and the freshness stated rather than assumed
- The application itself: the API, the product surface and the durable workflows behind it
- Agent persistent memory that reads through the same grants a person would
- Branching wired into the delivery pipeline, so a preview environment gets production-shaped data safely
- Point-in-time recovery and read replicas configured against a recovery objective somebody has agreed
Clients we have done this for
B2B ecommerce
DealerIQ
TotalLoop finds a dealership's customers with equity in their vehicle and matches them to cars on the lot. DealerIQ brought the idea and the dealership know-how, and our senior engineers worked inside its team to build it on Azure, test it with one dealer account and ship a lean first version. Later we moved it off Cosmos DB and SQL Server onto Databricks Lakebase, in waves that could each be rolled back.
Agentic GTM
Canvass
An application on Cloudflare that researches accounts and prepares outbound campaigns for Canvass's clients, where one bad email costs a prospect. A person approves every send, a run that dies halfway can't message a contact twice, and each email is checked again the moment it goes out.
Where this goes next
Web application development
The half of Lakebase work most data firms do not do
Databricks consulting
The wider engagement this usually sits inside
APIs and durable systems
What the transactional side needs underneath it
Agentic AI development
Where the persistent memory story goes
Lakebase versus Snowflake Postgres
Serverless and branching against a dedicated VM and full-copy forks
Building applications on Lakebase
The Gilbert user group session: a branch in 4.5 seconds, recovery from a bad UPDATE, live
We gave a talk on this
Our engineers organise the Databricks user groups in Gilbert and Dnipro, and a session is one thing built in the room rather than a deck about someone else's work. The slides are free to read.
FAQ
Lakebase implementation: common questions
What is Databricks Lakebase?
A fully managed serverless Postgres that runs inside the Databricks platform, using open source Postgres rather than a fork or a new SQL dialect.
Compute is separated from storage and scales to zero when idle, and it adds database branching, point-in-time recovery and read replicas. It registers as a catalog in Unity Catalog, so the governance you already run covers it.
What is Lakebase for?
Three things Databricks names: real-time transactional applications, persistent memory for AI agents, and operational data analytics where the operational copy and the analytical one have to stay in step. It is the operational database beside the lakehouse rather than a replacement for Delta tables.
Why do most Databricks partners struggle with Lakebase?
Because the database is the easy half. Lakebase asks somebody to build a transactional application on top of it, and that is application engineering rather than data engineering.
A firm whose decade is pipelines, dashboards and models has the wrong muscle for an API under request latency, a product surface people use all day, and a workflow that must never half-complete.
Why is TechFabric a good fit for Lakebase work?
We built custom software for a decade before we went deep on Databricks, and both benches are still here: 115+ engineers across four offices, 80 of them Databricks-certified, average fifteen years of production experience.
Lakebase sits exactly on the seam between those two things, which is an unusual place for a data consultancy to be strong and an ordinary one for us.
Should our operational database move to Lakebase?
Only where the operational and analytical copies genuinely have to reconcile, or where an application would rather read from inside the lakehouse than sync out of it.
A Postgres that already works, sitting far from your Databricks estate and reconciling fine, is not a migration worth paying for. We would rather say that in the first call than after a discovery.
How does Lakebase change how we ship?
Branching is the part teams underestimate. You create an instant branch of the database for a preview environment, reset it to production data, and the usual argument about test data being unrepresentative stops happening. Teams that wire that into the delivery pipeline usually see the biggest change in cycle time come from there rather than from anything the agent does.
Can agents use Lakebase for memory?
That is one of the workloads Databricks designed it for, and the governance is the reason it is worth doing there rather than in a side database.
Memory held in a Lakebase catalog registered in Unity Catalog is memory an agent reads through the same grants a person would, which is the difference between an agent you can put in front of customer data and one you cannot.
The rest of databricks
Databricks consulting
Data and engineering leaders choosing a Databricks partner
Hire Databricks engineers
Engineering and data leaders who need Databricks capacity quickly
Unity Catalog consulting
Platform and security leads who have to defend the setup to somebody else
Databricks cost optimization
Data platform leads whose Databricks bill is outgrowing the work
Data integration
Data, finance and operations leaders whose numbers live in five systems
Databricks data engineering
Data and analytics leaders running pipelines on Databricks, or moving onto it
Databricks MLOps
ML leads and heads of data science whose models stop at the notebook