Use Case
Two world-class databases.One conversation layer.
Minimal completes your data estate.
Postgres handles your transactions. ClickHouse handles your analytics. Both are exceptional at what they do. Minimal gives them a shared governance surface — one permission model, one activity log, one API layer — so your entire organisation speaks to both with the same confidence.
Great databases.One shared voice.
Postgres owns your transactional data — fast writes, relational integrity, the operational heartbeat of your product. ClickHouse owns your analytical data — billions of rows, sub-second aggregations, the intelligence layer of your business. Minimal gives both a shared API surface. One set of access rules. One audit trail. One runtime that speaks for both.
- One governance model across Postgres and ClickHouse simultaneously
- One activity log — every call to both databases in one place
- Access revocation: one action, both databases, instant
- Schema changes in either database — Minimal adapts at runtime
- Customers scoped to both their transactional and analytical data slice
One runtime.Both databases.One governance surface.
Connect Postgres and ClickHouse to the same Minimal project. Define personas and access rules once. They apply to both databases simultaneously. When a permission changes, it changes in one place and propagates to both your transactional and analytical API surfaces instantly.
One activity log
Every API call — Postgres or ClickHouse — in the same log. One place to audit. One place to investigate.
One permission model
Roles defined once govern access to both databases. A customer scoped to their Postgres data is simultaneously scoped to their ClickHouse analytics.
One config to change
Add a database, remove one, update connection details — one config update, no code changes.
Runtime governance
Governance lives in Minimal's runtime, not in the database — works identically across Postgres and ClickHouse.
The Difference
Postgres + ClickHouse, separately
Two API layers to build and maintain
Two permission systems to keep in sync
Access revocation: two separate actions
Two audit logs — no unified view
Schema change → update both layers
Compliance: two systems to evidence
Postgres + ClickHouse + Minimal
One runtime — both databases, one surface
One permission model — defined once, applies everywhere
Access revocation: one action, propagates instantly
One activity log — Postgres and ClickHouse together
Schema change → Minimal adapts at runtime
Compliance: one system, one audit trail
Postgres + ClickHouse, separately
Two API layers to build and maintain
Two permission systems to keep in sync
Access revocation: two separate actions
Two audit logs — no unified view
Schema change → update both layers
Compliance: two systems to evidence
Postgres + ClickHouse + Minimal
One runtime — both databases, one surface
One permission model — defined once, applies everywhere
Access revocation: one action, propagates instantly
One activity log — Postgres and ClickHouse together
Schema change → Minimal adapts at runtime
Compliance: one system, one audit trail
See it on live data.
No signup needed.
Try LiveOr apply for a Founders License — 100 unlimited licenses, free for 12 months.