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 remove 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, and leave any root certificate, CA bundle, or sslrootcert field blank — including your source database’s certificate bundle. A source CA can’t verify an Ardent branch URL, and some clients treat require plus a configured certificate as full verification, which causes TLS errors like a secure channel mismatch. Without a custom certificate, sslmode=require keeps the connection encrypted.
Keep channel_binding=disable in the URL. TLS ends at Ardent’s 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 write the SQL, so you control 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 manages the service.Talk to us
Contact vikram@tryardent.com to run the data plane in your cloud.