One Database, Many Responsibilities

Summary

LKCI currently uses one Postgres database for multiple responsibilities, but the architecture treats those responsibilities as separate from the start.

Problem

A shared database can make boundaries look optional. If analytical, operational, execution, and review state all live in one physical system, code can start joining across them casually. That makes future separation harder and blurs who owns truth.

Principle

Physical colocation is not conceptual ownership. The platform can use one database today while writing code as if OLTP state, lakehouse truth, and ops execution state may split later.

Platform Shape

Lakehouse schemas such as bronze, silver, and gold own ingestion, canonicalization, history, and analytical facts. Domain OLTP schemas own interactive state, review, issues, approvals, queues, and serving state. The ops schema owns execution and support state such as job runs, DAG runs, schedules, sync audit, and messaging support.

That separation affects code. UI surfaces should not assemble state from raw analytics joins. Pipelines should not mutate review state directly. Jobs should record execution through platform runtime primitives rather than hidden local state.

Source Evidence

  • AGENTS.md
  • docs/reference/architecture.md
  • docs/domains/lakehouse.md

Tradeoffs

The platform sometimes writes extra publish steps or service boundaries even when a direct SQL query would be shorter. That is the cost of keeping future database and service splits possible.

  • docs/engineering/architecture/oltp-vs-analytics-boundaries.md
  • docs/engineering/architecture/lakehouse-service-boundary.md