Architecture

Documentation Index

Fetch the complete documentation index at: https://docs.tryardent.com/llms.txt

Use this file to discover all available pages before exploring further.

Ardent follows a split-plane architecture like databricks where the control plane and data plane are separated:

• Control plane: Operated by Ardent. Handles branch orchestration, replication health monitoring, connection routing, auto-scaling, and policy enforcement. Spans across all deployments.
• Data plane: Where your data lives. Includes the ardent replicator, kafka, your read replica, cloned databases and more. Can be deployed on your cloud or ours.

Only metadata (schema structure, replication status, branch state) flows from the data plane to the control plane. Your actual data never leaves the data plane.

​

How it works

​

Control plane

Always operated by Ardent. Orchestration, policies, routing, and visibility across every branch and connection.

• Branch lifecycle: Create, suspend, delete, and route traffic to the right branch. Connection URLs go through Ardent’s proxy so every session is tied to an account and can enforce rules, hooks, and policies as well as prevent leakage of raw URLs for safety.
• Replication coordination: Monitors health, lag, and pipeline status from metadata; scales and manages the Kafka layer that backs replication so you are not sizing or operating brokers yourself.
• Connector setup: Discovery and validation when you connect a database, plus connector-scoped settings such as default database and branch SQL hooks.
• Auth, usage, and billing: Org access, API keys, and metering. Per-user and per-branch visibility Postgres does not give you out of the box.

​

Data plane

Where your data physically lives and where branches are served from. Runs on Ardent’s infrastructure (fully managed) or in your own cloud account (managed, your cloud).

• Ardent Replicator
  • Takes logical replication from production through a Kafka-backed pipeline into the read replica.
  • Handles DDL in flight using custom event triggers that detect DDL on the primary and replay it in order on the replica, so schema changes keep streaming without stalls or silent drift.
  • Applies changes in order across failures so retries do not leave gaps or duplicates.
  • Manages WAL and slot pressure so replication does not destabilize the primary.
  • Quarantines, resumes, and recovers broken streams without manual replay scripts.
• Read replica: Stays in sync with production; branches are always created from the replica, never from production directly, so branch load never hits your primary.
• Branches (compute and storage): Each branch is a full Postgres instance with compute that auto-scales with load. Branches share storage from the same replica through copy-on-write, so scaling to many branches is efficient for both compute and storage. Queries and connections run independently on autoscaling branch compute.
• Isolation: Your data stays inside this boundary. Only metadata crosses to the control plane. This means in a BYOC model you can maintain residency of all your data without losing Ardent’s ability to manage the service

You connect your database and open branches. The control plane orchestrates; the data plane runs replication, the replica, and branches.

---

​

Deployment options

Ardent orchestrates everything from our control plane. The data plane is the only thing that moves. Both modes are fully managed by Ardent. The difference is where the data plane runs. Fully managed. We host the entire data plane. Connect your database and we handle the Ardent Replicator, Kafka pipeline, read replica, and branch compute. Managed, your cloud. Same managed experience, but the data plane deploys into your own cloud account. Your data never leaves your infrastructure. The control plane still orchestrates everything via API; all replication and branch compute runs inside your network.