ENNL
Book a call

Data platforms

OLTP, OLAP and Lakebase: one platform for apps and analytics

Transactional and analytical workloads need different designs. Lakebase and LTAP aim to serve both from one governed copy of the data, and we engineer the move step by step.

Plan a callDatabricks health check

01 / Two workloads

Two workloads, two designs

OLTP records what happens. OLAP explains what happened. Each has a design that suits it.

OLTP: running the business

  • Records what happens: an order, a booking, a message
  • Every change is correct at once (ACID)
  • Many users write at the same time
  • Answers in milliseconds
  • Holds the current state

OLAP: understanding the business

  • Explains what happened: trends, totals, forecasts
  • Reads whole columns across many rows
  • Loads in batches or streams
  • Answers in seconds, over history
  • Feeds reports, forecasts and ML features
OLTP and OLAP side by side
OLTPOLAP
Typical questionWhat is the status of this order?How did late deliveries develop per route?
Access patternMany small reads and writes of single rowsFew large scans and aggregations over many rows
Storage layoutRow-oriented, with indexesColumnar, compressed
LatencyMillisecondsSeconds
ConcurrencyHigh: many users and requests at onceLower: fewer, heavier queries
Data keptCurrent stateHistory
ExamplesOrders, bookings, app state, agent memoryReporting, forecasting, ML features

02 / Two systems

What breaks between two systems

A common set-up runs both and joins them with pipelines. That glue is where cost and delay collect.

  1. App databaseOLTP, current state
  2. CDC and replicasCopy changes out
  3. LakehouseOLAP, history
  4. Reverse syncCopy results back
  5. ApplicationUsers and agents
  • Fragile syncCDC pipelines and replicas are costly and run behind.
  • Schema changesA changed schema breaks the sync, which also competes with the app database for resources.
  • Stale answersDashboards and agents act on data that lags behind the application.
  • A second copyYou pay for it and govern it separately.
  • Outside the catalogueThe operational side sits outside Unity Catalog.

03 / Lakebase

What Lakebase is

Lakebase is a managed, serverless Postgres service on Azure Databricks, governed in Unity Catalog next to your lakehouse.

  • Serverless PostgresIt scales to zero when idle.
  • Branches in secondsZero-copy branches of production data.
  • Point-in-time recoveryInstant restore to an earlier moment.
  • pgvector and extensionsDozens of Postgres extensions, pgvector included.
  • Governed in Unity CatalogRegister the database for unified governance.
  • Synced tablesUnity Catalog tables become low-latency reads for applications.

A branch holds a copy of production data, so a schema change is tested before it merges.

Branch per pull requestIllustration
# Schematic flow, not real commands or configuration
pull_request_opened:
  create_branch: copy of production data
  run: schema migrations on the branch
  run: integration tests on the branch
pull_request_merged:
  apply: migrations to production
  delete: the branch

What else we check

  • Microsoft Entra ID and Azure networking protections are part of the service. We review them against your landing zone.
  • Read replicas and automatic failover exist. We confirm their current status before design.
  • Lakebase Change Data Feed stores Postgres changes as Delta with full history. It is in Public Preview.
  • Databricks
  • Lakebase
  • Unity Catalog
  • PostgreSQL
  • Microsoft Entra ID

04 / LTAP

LTAP: what is ready today

LTAP is an architecture that serves OLTP and OLAP from one copy of the data. Some parts are generally available, others are still in preview.

LTAP capabilities and their status
CapabilityWhat it doesStatus
Lakebase in Unity CatalogRegisters the Postgres database for unified governanceGA
Synced tablesBring Unity Catalog tables into Lakebase for low-latency readsGA
Change Data FeedStores Postgres changes as Delta with full historyPublic Preview
LTAP Direct WritesAn LTAP capability, described in the Databricks documentationBeta
Lakehouse queries LakebaseThe lakehouse reads Lakebase data in real timePrivate Preview

Our rule: only GA capabilities go to production. Preview features run in a branch or a test environment. Last verified: 10 November 2026.

What LTAP aims to do

LTAP (Lake Transactional/Analytical Processing) was announced on 16 June 2026. It aims to remove the CDC, replication and transformation pipelines between the transactional and the analytical side. Databricks says LTAP is coming soon as a part of Lakebase.

05 / Fit

When Lakebase fits, and when to keep what you have

Stay, or assess first

  • Large Postgres estates with heavy tuning
  • Workloads that depend on capabilities still in preview
  • Requirements we have to verify per region

Good fits

  • Operational apps beside the lakehouse
  • Agent memory and state
  • Serving features and scores to apps
  • Replacing a small operational data store and its sync jobs

06 / Engineering

How we engineer it

Five stages, each with checks you can inspect.

  1. Design

    We review networking and identity against your Azure landing zone. Entra ID groups and Unity Catalog reader and contributor groups per schema give least privilege.

  2. Build as code

    Terraform modules and Asset Bundles define the platform. Only pipelines deploy them, through dev, test, acceptance and production.

  3. Branch and migrate

    Every pull request gets its own database branch. Schema migrations run on that branch and are tested before the merge.

  4. Prove

    We load test with production-like volumes and run restore drills, so recovery is a step you have rehearsed.

  5. Run and hand over

    Cost budgets and alerts watch the spend. You receive a runbook and a handover session.

Governance for AI

One gateway for every model, agent and tool

Every call from teams, agents and coding tools passes through Unity AI Gateway, so access, spend and logs follow the rules of the rest of your data.

  1. Teams, agents, coding toolsWhoever calls a model
  2. Unity AI GatewayPermissions, budgets, limits, policies, logging
  3. Models, MCP servers, toolsDatabricks-hosted and external
  • AccessUnity Catalog privileges decide who may use what.
  • Budgets and limitsSpend and request rates have a cap per use case.
  • PoliciesRules apply to requests and responses.
  • LoggingEvery call lands in Delta tables for audit.
  • RoutingTraffic splits across models, with failover.

How we set it up

  • The gateway and its policies are defined as code and deployed by pipeline, never clicked together.
  • One service per use case, each with its own budget and an owner who answers for it.
  • Inference tables with a retention period and access groups, so logs are useful and not a liability.
  • System-table dashboards for tokens, cost and latency per team.
  • Coding agents such as Claude Code are routed through the gateway, with repository rules and review gates on top.
  • Fallbacks are tested before go-live, by switching a destination off on purpose.
  • Smart Routing stays out of production while it is in Beta.

Generally available. Smart Routing is in Beta. Last verified: 10 November 2026. Unity AI Gateway documentation

07 / FAQ

Questions we hear

Is Lakebase a replacement for our data warehouse?

No. Lakebase serves applications that read and write single rows. Analytical queries over history stay on the lakehouse. LTAP aims to let both work on one copy of the data.

Do we still need CDC?

Synced tables are generally available and bring Unity Catalog tables into Lakebase. The capabilities that aim to remove CDC in the other direction are still in Beta or preview, so we plan for CDC until they are generally available.

Can agents use Lakebase as memory?

The pattern fits: agent memory and state are current-state data in small reads and writes, and pgvector is among the supported extensions. We design retention, access and evaluation together with the agent.

What about preview features?

Production uses only generally available capabilities. Preview features run in a branch or a test environment, and we re-check their status on a fixed date.

Where does the data live?

Lakebase is a managed service of Azure Databricks. Where exactly the data sits depends on the region and the network set-up, so we verify both against the current documentation and your landing zone before design.

Sources, last verified 10 November 2026

Related

Why a data platform pays off Data platforms AI engineering

Next step

Planning apps and analytics on one platform?

Tell us what runs today and where the pipelines hurt. We will say what to move, what to keep and what to test first.

Discuss your platformSend a messageor email info@nexops.nl directly

Currently accepting projects for Q4 2026