Loading…
Topic
Lakebase
53 posts about Lakebase. Every summary links to the original.
- 53 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Sizing Lakebase Search: lessons from a real app and 4 million passages
Slide Hub, an internal Databricks app for slide search, uses Lakebase Postgres with Lakebase Search extensions (lakebase_vector and lakebase_text) to run hybrid vector and BM25 search on the same database as application data. The app stores 23k slides and indexes up to 4M passages from the MIRACL English corpus. Benchmarking shows that below 8 Compute Units (CU), Lakebase Postgres is the bottleneck; above 8 CU, the app’s worker count limits throughput. Candidate pool size significantly affects cold-start latency: 200 candidates preserves 90.5% of top-10 results while touching a third of the pages of 1,000 candidates. A 14-minute load test cost 0.13, with Lakebase compute billing only while active. For production, a 0.5 CU minimum costs ~ 31-40/month and avoids cold-start delays.
Real-Time Retail Intelligence: Building E-Commerce Recommendations with Lakebase and AI Search on Databricks
The post presents a reference architecture for building a production-grade e-commerce recommendation system on Databricks, based on a real-world implementation for a leading fashion e-commerce platform in Asia serving over 1 million monthly active users across 100,000+ SKUs. The system ingests approximately 1,000 events per second via Lakeflow Connect’s Zerobus into Unity Catalog Delta tables within a medallion architecture. Serving uses two paths: Path A for pre-computed batch recommendations via key-value lookup from Lakebase online tables, and Path B for real-time session-aware scoring using AI Search and a LightGBM model in a 3-stage funnel. The architecture unifies ingestion, feature management, model training, vector retrieval, and serving on a single governed platform, with cold-start handling for new users and products. Expected outcomes include low 2-digit millisecond responses, daily-fresh recommendations, and unified governance via Unity Catalog.
A practical guide to cost optimization with Lakebase Postgres
Lakebase uses separated storage and compute to reduce costs: branches share storage, autoscaling matches compute to demand, and scale to zero suspends compute after inactivity. Read replicas and high availability add compute without duplicating storage. For synced tables from Lakehouse, sync only the active working set via materialized views and choose the appropriate sync mode—snapshot for volatile data, triggered for incremental, continuous for real-time—and binpack tables into one pipeline to share compute. Right-size initial compute by focusing on the working set, and set PITR retention and snapshot schedules based on actual recovery needs. Snapshot storage is priced at $0.090/GB-month and PITR storage at $0.200/GB-month, both cheaper than regular branch storage. Compute and storage usage can be tracked through system.billing.usage, with separate SKUs for compute, branch storage, PITR, and snapshots.
Zero downtime patching lakebase part-1 prewarming
Lakebase addresses the workload disruption caused by planned PostgreSQL maintenance, where a restart clears in-memory buffer and local file caches. Although the database can return in about one second at P99, the source reports a roughly 70% pgbench TPS reduction while caches warm, potentially causing timeouts. Lakebase uses stateless Postgres compute replicas and disaggregated shared storage to prewarm a replacement compute before a scheduled restart. The control plane transfers cached-page information, loads pages from shared storage, and follows relevant WAL from Safekeepers, while the current primary continues serving traffic. After prewarming, Lakebase promotes the new compute with PostgreSQL’s pg_promote without restarting the server; tests on 10 GB pgbench workloads found nearly instant throughput recovery, especially for read-only queries.
Database Branching in Postgres: Git
Shared staging databases often drift as schemas diverge, test data accumulates, and developers avoid creating isolated environments because traditional pg_dump copies are slow and expensive. Databricks Lakebase Postgres addresses this with database branching, which creates fully isolated environments from a parent’s exact schema and data at a point in time. Branches use copy-on-write: they share underlying versioned storage until a branch changes, then record only new data, while each branch has independent compute and a separate connection string. Idle branches scale compute to zero, and storage cost tracks changes rather than the full database size. This supports per-developer, per-pull-request, per-test-run, and recovery workflows, including point-in-time branching within the restore window, with the source describing branch creation through the console, CLI, or API in under a minute.
Managed Postgres: What Lakebase Actually Takes Off Your Plate
Managed Postgres varies from OS patching alone to operating scaling, failover, backups, recovery, and related database tooling. Lakebase Postgres applies this model to serverless infrastructure, offering automatic scaling, scale-to-zero, PostgreSQL compatibility, automatic snapshots, point-in-time recovery, branching, built-in PgBouncer, and support for extensions including pgvector and PostGIS. Within a region, patching, scaling, failover, and backups run automatically, while encryption, access control, audit visibility, connection pooling, and lakehouse integrations are also addressed. The discussion also stresses checking PostgreSQL versions, configuration, extensions, and migration methods before moving an existing database. Cross-region disaster recovery remains the main exception: it is in Private Preview for AWS, with periodic replication, manual failover, and customer-managed recovery procedures.
Introducing Consort: Test-driven development on a branching database
Consort is introduced as an open-source agentic development framework for test-driven development on branching Lakebase Postgres databases. It addresses the limitations of mocks, shared staging databases, and risky schema-change ceremonies by bringing integration testing into the inner loop. Its build lane runs red/green/refactor cycles against isolated copy-on-write branches of real data, while versioned migrations keep code and schema changes together and pull-request checks test migrations against fresh branches. Consort organizes work through role-based agents and a deterministic conductor, preserving feature artifacts in dedicated directories and supplying scoped context packages. A VS Code plugin pairs Git and Lakebase branches, while an observability dashboard exposes agent turns and human approval gates; the project is community-supported rather than a bundled platform feature with an SLA.
Build durable agents with Temporal and Lakebase
Long-running personal-loan underwriting agents must preserve completed work, resume after worker failures, tolerate repeated tool calls, wait for reviewers, expose operational state, and retain an audit trail. The reference implementation combines Temporal durable Workflows and Activities with Lakebase Postgres, using Temporal Event History for replay and Lakebase schemas for run status, evidence, review state, messages, and metrics. Deterministic identifiers, constraints, guarded updates, and Postgres upserts make repeated Activity attempts target the same logical records, while Signals carry human decisions and long waits do not occupy workers. A Unity Catalog synced table supplies governed underwriting policy, and optional Change Data Feed publishes operational changes to Delta history tables. The implementation includes a React/FastAPI interface, mocked deterministic providers, OAuth credential refresh, and 21 passing tests, but does not validate production lending, compliance, security, scale, or an observed end-to-end feed.
Simplify AI agent orchestration with Lakebase Postgres
CLA and Databricks built a production document-processing application for auditing that reduces extraction time from hours to minutes without compromising quality, using Databricks-native services including Lakebase Postgres, Databricks Apps, Lakeflow Jobs, MLflow, and Unity Catalog Volumes. Lakebase serves as the orchestration layer’s single source of truth for tasks and execution attempts, coordinating long-running work, retries, leases, priorities, rate limits, costs, and status visibility. The queue uses Postgres patterns including FOR UPDATE SKIP LOCKED, priority and FIFO ordering, expiring leases for crash recovery, and database-backed concurrency controls. Databricks Jobs process PDFs through intelligent document processing and vision/LLM calls, while MLflow Tracing records execution and cost details and dashboard updates combine fast Postgres data with slower billing queries. In production, this architecture avoids external brokers and schedulers while providing durable task management, real-time visibility, and per-task cost attribution.
Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort
Glaspoort replaced a sprawl of outdated, one-off BI reports with a custom application that combines Databricks analytical tools with Lakebase, a serverless Postgres OLTP database. The application keeps curated lakehouse data in a read-only schema while application state occupies a separate schema, and supports development, acceptance, and production environments. Its CI/CD pattern treats database branches like code: long-lived environments branch directly from production, each pull request receives an ephemeral production-shaped branch, migrations are replayed, and a staging app image runs the full test suite against it. This topology makes periodic resets cheap, avoids deleting dependent branches, and preserves fresh test data; the team chose stacked promotion for velocity, retaining a separate crisis pipeline for urgent fixes.
Tech builds on AI. Finance protects the margin.
AI-native tech companies must protect unit economics as agents accelerate changes in compute consumption, pricing, and revenue recognition, while gross margins remain below classic software levels. Finance teams built around extracts, spreadsheets, and monthly reconciliation can miss repricing changes, metering errors, and compute-commitment risk. The proposed foundation is an evolving ontology that keeps product, plan, usage, and cost meanings current, with Stripe data entering Unity Catalog through OpenSharing and Lakebase providing transactional Postgres on the lakehouse. Genie One uses that ontology to answer governed, sourced questions about gross margin, consumption revenue at risk, and compute spend, while people retain decision authority. The post describes organizations using Databricks to consolidate reporting, forecasting, workflows, and finance applications, positioning a shared data-and-AI platform as the path from an initial answer to an ongoing finance platform.
Building a soccer coaching app on Databricks
Coach’s Corner, also called La Pizarra, turns high-frequency soccer tracking data into a bench-side application for replay, tactical analysis, scouting, standings, and agent-generated dossiers. Built as a Databricks App, it ingests NDJSON feeds at 25 frames per second through Auto Loader and Spark Declarative Pipelines, enforcing 46 data-quality expectations across bronze, silver, and gold layers. Liquid clustering supports 1–3-second DBSQL queries, while Lakebase synchronizes gold data to Postgres for millisecond replay reads and separates sequential playback from exploratory analytics. The scouting layer grounds Genie, Vector Search, a Unity Catalog-registered xG model, and an Agent Bricks supervisor in governed data, with Claude calls routed through the Unity AI Gateway, MLflow tracing, and a deterministic fallback. Together, these components are presented as a way to deliver traceable insights within seconds without forcing coaches to interpret raw tables or analysts to relay every result.
What happens in the milliseconds after you tap pay
At checkout, fraud scoring must combine transaction inference with customer-specific rules while keeping latency low enough for an interactive payment. The retail-app sample pairs a FastAPI backend and React frontend in a Databricks App with Model Serving route optimization and Lakebase Postgres, where the model retrieves historical features and the backend reads profile controls. A transaction is scored first, then checked against daily spending, international-transaction, and country rules; pooled OAuth-authenticated connections and token-rotation handling avoid repeated handshakes and stale credentials. In the supplied benchmark, route-optimized calls reached 27.2 ms p50 and 37.3 ms p95 end-to-end, with feature lookup at 8.9 ms p50, CatBoost inference at 0.4 ms, and network overhead at 17.4 ms p50; actual performance varies by model.
Data-Native AI Agents: Why Agents Must Move to Your Data
Enterprise AI pilots often move data into separate vector databases, SaaS LLMs, or serving layers, creating governance gaps, compounded latency, fragmented costs and observability, and duplicated lifecycle work. The post advocates data-native agents: models, agents, tools, retrieval, and memory run inside the governed data platform, with policy enforced during query planning and computation rather than after responses are produced. It argues that post-hoc controls cannot undo sensitive information encoded in aggregations and can trigger token-burning retry loops. For state and memory, it presents Lakebase, managed PostgreSQL within Databricks, as transactional storage and a shared source of truth for multi-agent swarms. The described platform pattern combines Unity Catalog, Unity AI Gateway, Model Serving, MLflow 3, AI Search, Lakebase, and business-context services, and recommends inventorying workloads already outside the perimeter before closing seams incrementally.
Foundational context: Cross-industry & function-specific accelerators for Lakebase
Databricks presents Lakebase as a fully managed, serverless, standard Postgres database for combining operational and analytical workloads on its Data + AI Platform. The platform separates compute from storage, integrates with the lakehouse through Synced Tables and Lakebase CDF, and uses Unity Catalog for governance; copy-on-write branching and autoscaling to zero are described as core infrastructure primitives. The post showcases partner-built, ready-to-deploy accelerators spanning technology, finance, marketing, sales, supply chain, human resources, customer service, and operations. Examples include PostgreSQL migration assessment, multi-agent Genie orchestration, stateful enterprise agents, autonomous data reliability, governed contact-center intelligence, and project operations management. These offerings package Lakebase patterns into migration controls, domain-specific solutions, and agent frameworks intended to accelerate modernization and reduce transformation complexity.
Introducing Feature Views
Feature Views are presented as a framework for creating managed feature pipelines in Databricks, addressing duplicated logic, training/serving skew, backfills, online-store plumbing, and governance for real-time ML. A Feature View defines the source, entity, time-series column, and computation once; Databricks uses it to generate point-in-time-accurate historical data, then materializes pipelines for batch or streaming production use. Registered in Unity Catalog, materialized features receive lineage and access controls, while MLflow records model dependencies and Model Serving retrieves required features without custom lookup code. For Kafka-sourced streaming features, Spark Realtime Mode, Lakebase, and Model Serving support rolling-window updates with reported end-to-end p99 latency of 200ms from event to online availability. The announcement says Feature Views are in Public Preview and can be developed through the Feature Engineering Client SDK and Genie Code, with streaming materialization requiring an Enterprise-tier workspace in a region supporting Lakebase.
The ambulatory intelligence gap
Health systems face an ambulatory intelligence gap: access, provider capacity, referral retention, panel management, and financial performance are interconnected, while information remains scattered across disconnected systems. Health Catalyst’s Ambulatory Intelligence combines AI with nearly two decades of healthcare improvement expertise, deploying directly in a customer’s Databricks workspace so sensitive data stays within the health system’s environment. It uses a medallion-based semantic layer, Unity Catalog for governance, Lakebase for low-latency serving, and Genie alongside dashboards to help leaders investigate why metrics change. The solution ships with prebuilt metrics across Access Optimization, Revenue Intelligence, Panel Management, and Referral Insights, plus cross-domain scorecards and configurable terminology and workflows. Reported outcomes from supported improvement work include increased revenue and encounters at Thibodaux Regional, 55,000 closed care gaps at INTEGRIS Health, and higher outpatient visits with fewer cancellations without reschedules at WakeMed; future plans include models based on prior outcomes and agentic capabilities.
Beyond dashboards: Introducing Decision Execution Platforms
Databricks Forward Deployed Engineering introduces Decision Execution Platforms (DEPs), an enterprise analytics category intended to connect KPI signals, executive decisions, operational execution, and measured outcomes. The proposal addresses workflows in which dashboards reveal problems but meetings, decks, spreadsheets, and messaging threads leave implementation fragmented and impact measurement disconnected. DEPs run the four-stage loop on governed Databricks infrastructure: agents recommend actions, alternatives, predicted impact, and reasoning; approved choices execute through systems of record; and results persist in a Decision Log for continuous learning. Their architecture combines a foundation of Lakebase, Genie, Unity Catalog, Lakehouse, Agent Bricks, and MLflow with an SDK of reusable primitives and a Databricks Apps executive surface. A retailer case used a DEP to unify fulfillment data and enable simulated, controlled rerouting, with scaling aimed at measurable bottom-line and customer-satisfaction outcomes.
From monolith to Lakebase to LTAP: rethinking the database from storage up
The post examines why monolithic OLTP databases become fragile and difficult to scale when compute, the write-ahead log (WAL), and data files share one machine. Using Postgres as its primary example, it contrasts local WAL durability and physical cloning with Lakebase, whose stateless Postgres compute externalizes those components into SafeKeeper and PageServer services. SafeKeeper replicates log records across a quorum through Paxos-based network replication, while PageServer applies the WAL and materializes data in cloud object storage. The resulting separation is presented as a way to improve durability, independently scale reads and writes, isolate workloads, and support high availability and branching without physical database clones. LTAP extends the design by making transactional tables directly queryable for analytics from a single governed copy, avoiding CDC or mirroring and allowing transactional and analytical engines to scale independently.
What Is Serverless PostgreSQL?
Serverless PostgreSQL is presented as a fully managed cloud database model that decouples compute and storage, allowing each to scale independently with demand. Traditional deployments require teams to size infrastructure, manually manage scaling, and absorb costs from idle capacity. In serverless systems, the provider provisions compute on demand, can suspend it when idle, and bills according to active usage; scale-to-zero may introduce cold-start latency. The architecture can also support database branching through copy-on-write, creating isolated environments without duplicating data. The article distinguishes this model from lakebase architecture, which combines transactional and analytical workloads on a shared foundation using decoupled compute, durable object storage, log-based storage systems, and orchestration.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.