How Hamlet Uses Databricks Lakebase to Test Changes Against Production Data

Starting from Public-Sector Pain Points: Hamlet's AI Decision Platform

Hamlet is an AI-driven platform whose goal is to make local government decision-making accessible and understandable. Public-sector decisions often involve large volumes of documents, meeting records, and complex approval processes, making it hard for ordinary people to trace the logic and rationale behind them. Hamlet tries to use AI to structure this information, helping residents, journalists, and officials see more clearly "how decisions are made."

This kind of product has very high requirements for data reliability: once conclusions are generated based on incorrect or outdated data, the damage affects not only user experience but also public trust. Therefore, Hamlet must solve a classic engineering challenge—how to validate every change using real production data without contaminating the production environment.

The Testing Dilemma: Production Data Can't Be Used Casually, but Synthetic Data Isn't Real Enough

The traditional approach is usually to use anonymized or synthetic datasets in a staging environment. But for a platform like Hamlet, the problem is that local government decision data is highly context-dependent, and synthetic data struggles to reproduce edge cases in real scenarios—such as specific meeting-record formats, citation relationships between historical versions, and cross-document entity associations.

If you only test with synthetic data, many problems won't surface until after launch. And testing changes directly on the production database carries obvious risks: it may write dirty data, affect the stability of online queries, or even break data consistency. Hamlet needs something in between—something that provides the real shape of production data while remaining isolated from the online environment.

Database Branching is a database engineering practice that has emerged in recent years. Its core idea is borrowed from Git's branching model: derive a logically independent, physically isolated database copy from a certain point in time of the primary database. Branches are typically implemented using copy-on-write (CoW) or storage snapshot technology, so they are cheap and fast to create and do not consume storage equal to the primary database. Developers can freely perform schema migrations, data modifications, and query stress tests on the branch, with all writes confined to the branch. Once testing is complete, the branch can be deleted directly, leaving the primary database's history and state unaffected. This mechanism solves the problem that traditional staging environments require periodic synchronization and are prone to drift, making it possible to simultaneously achieve the two goals of "testing with real data" and "not polluting production."

Databricks Lakebase Postgres as the Entry Point

According to Databricks' official description, Lakebase Postgres is a service that combines a Postgres-compatible database with data lake capabilities. Its key value is that developers can create independent database branches based on production data, and perform schema changes, query testing, and feature validation on the branch without affecting the primary database.

Hamlet adopts exactly this approach. Instead of maintaining a staging dataset disconnected from production, the team derives an isolated Postgres branch from the production environment and runs the changes to be tested on that branch. After testing is complete, the branch can be discarded, and the primary database is unaffected.

The benefits of this model are twofold: the data used for testing remains structurally identical to production, so edge cases are naturally covered; and because the branch is isolated, writes and queries during testing do not flow back online. For a platform like Hamlet that relies on real decision data for reasoning, this is close to ideal.

Engineering Benefits: From "Guessing Launch Risk" to "Validate Before Launching"

Several points from Hamlet's practice are worth referencing for similar teams:

• Test fidelity from real data shape: Branch data inherits the structure and content characteristics of the production database, avoiding the gap between synthetic data and real distributions—especially in scenarios involving LLM inference pipelines, where subtle differences in input data can significantly affect output quality.
• Isolation reduces change risk: Database branches are separated from the primary database, so operations such as schema migrations, index adjustments, and query rewrites can be validated on the branch first, reducing the probability of rollbacks after launch.
• Environment consistency: There is no longer a need to maintain a staging environment that may gradually drift from production, reducing problems like "it runs locally but errors online."

For AI application teams, the third point is especially important. The behavior of AI systems is highly sensitive to data state, and environment drift often appears in the form of hard-to-reproduce bugs. Using an isolated branch of production data for validation essentially brings the "data environment" into the scope of what can be tested.

Environment Drift refers to the phenomenon in which a test environment gradually diverges from the production environment in data, configuration, or dependency versions. Traditional staging environments are often highly consistent with production early in a project, but as the production database continuously writes new data and performs schema changes, staging falls out of sync with the real state if it cannot be updated accordingly. For AI applications, the harm of environment drift is especially insidious: model inference is sensitive to the distribution, format, and context length of input data, so tests that appear normal in staging may output anomalies after launch due to long-tail samples in real data. Using production data branches can fundamentally eliminate drift in the data dimension, because the branch itself is an exact projection of the production state at a certain moment.

Implications for AI Application Developers

Hamlet's case reflects a broader trend: as AI applications move deeper into the core of business, testing strategies need to expand from "code correctness" to "data and behavior correctness." Traditional CI/CD processes focus on builds, unit tests, and integration tests, but the output quality of AI systems also depends on the authenticity of input data and the completeness of context.

The branching capability provided by Databricks Lakebase Postgres can be seen as an attempt to connect database version control with the testing process. It enables teams to obtain a "production-like" test environment at low cost while retaining isolated control over data.

Of course, this approach is not zero-cost: branch creation and management, the timeliness of data synchronization, and permission and compliance boundaries all require teams to make corresponding process designs. For Hamlet, which handles sensitive government data, how to comply with data governance requirements within isolated branches may be an area requiring ongoing investment.

Overall, Hamlet's practice of testing changes with Lakebase Postgres branches provides a referenceable engineering paradigm for AI application teams: don't choose between production and simulation—use isolated copies of production data to validate real-world behavior.

One-line Summary

Hamlet uses Lakebase Postgres production data branches to test changes to its AI decision platform, balancing realism and isolation.

Paragraph Summary

This article describes how Hamlet uses the database branching capability of Databricks Lakebase Postgres to solve testing challenges for AI applications. The local government decision platform Hamlet has extremely high requirements for data reliability, but synthetic data in traditional staging environments struggles to reproduce the context dependencies and edge cases of real decision data, while testing directly on the production database carries contamination risks. Lakebase Postgres allows isolated branches to be derived from production data; the team can perform schema changes and query tests on the branch, then discard the branch afterward without affecting the primary database. This approach delivers three benefits: real data shape improves test fidelity, isolation reduces launch risk, and environment consistency reduces hard-to-reproduce bugs. The article concludes that AI application testing must expand from code correctness to data and behavior correctness, while branch management, data synchronization, and compliance permissions still require supporting design.