Minimal production footprint
Ardent uses logical replication to sync your table data and does not write to your application tables. During connector setup, Ardent creates one dedicated schema for its own metadata and installs DDL event triggers there so schema changes replicate correctly. Replication has minimal performance impact on production. Normal application reads and writes continue against your database as usual.Encryption and secrets
Ardent encrypts source database credentials, API keys, and connection secrets at rest. Credentials are read only at runtime, when Ardent needs to connect to your database. With BYOC (bring your own cloud), secrets live in your own infrastructure (for example AWS SSM Parameter Store). Ardent reads them directly from your secret store at runtime, and your credentials never leave your network. Every branch gets its own generated connection string. If a branch URL is ever compromised, it has zero access to your original database. This makes it safe to hand branch URLs to AI agents like Claude Code or Cursor without leaking your source database credentials. Branches are controlled through Ardent’s control plane, so you can delete or de-provision them at any time.Branch connection TLS
Branch connection URLs include?sslmode=require&channel_binding=disable. Use the URL exactly as Ardent returns it.
Set SQL clients and IDEs to SSL mode require. With no custom root certificate configured, sslmode=require encrypts the connection but does not validate a CA chain. Do not load a custom root certificate or CA bundle for branch connections, including the certificate bundle from your source database. If your client has a root certificate, CA bundle, SSL certificate authority, or sslrootcert field, leave it blank.
Some PostgreSQL clients treat sslmode=require plus a configured root certificate as certificate verification. A source database CA bundle cannot verify an Ardent branch URL and can cause TLS errors such as a secure channel mismatch. Clearing the custom certificate keeps the connection in TLS-required mode.
Keep channel_binding=disable in the URL. Ardent terminates TLS at the routing layer, so clients that force channel binding can reject an otherwise valid branch connection. If your client exposes channel binding, set it to disable or off.
Branch anonymization
Branches default to a full copy of your production data. When you need realistic schema and relationships but not real PII, you can run SQL on every new branch from this connector after it is created. Set it with the CLI:@path).
Your script might UPDATE columns to hashed or synthetic values, redact free-text fields, or trim tables that should never leave production. The script runs once per branch. If Ardent re-runs it for the same branch, successful runs are not repeated.
This is the same branch_sql setting documented in CLI settings. There is no separate anonymization toggle: you own the SQL, so you stay in control of exactly what changes.
Each branch is a fully independent copy. Changes on one branch don’t affect production or any other branch. When you’re done, delete it or let it auto-suspend. Nothing persists unless you want it to.
Data residency
In fully managed mode, your data lives on Ardent’s cloud infrastructure. In managed, your cloud mode, the entire data plane (read replica, branches, and secrets) lives in your own cloud account. Your data never leaves your network. Ardent still manages everything via the control plane. For teams with data residency or compliance requirements, the managed, your cloud deployment keeps all data and credentials inside your infrastructure while Ardent handles orchestration.Talk to us
Contact vikram@tryardent.com to run the data plane in your cloud.