logoalt Hacker News

Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration

85 pointsby vc289yesterday at 4:54 PM34 commentsview on HN

Hey HN! We’re Vikram and Evan from Ardent (https://tryardent.com). We're building database sandboxes for you and your coding agents.

In the last two years coding agents have gotten dramatically more capable at handling complex engineering tasks. But without access to a realistic sandbox at the DB layer for testing, they ship garbage that can take down production databases. I spent over a year building an AI Data Engineer that failed for this exact reason. Evan spent the last 12 years in data engineering and hit this wall building agents at his last company.

Ardent was built to make it possible for coding agents to get near instant access to production-like sandboxes so they can test their work. To do this we write a replication stream out of the target DB, scaling with kafka onto a read replica with copy on write enabled and autoscaling compute (we currently prefer neon as a primary branching engine due to their implementation of these properties).

Our replication stream uses logical replication + ddl triggers to enable usage on any hosted postgres DB since most platforms do not allow physical replication which is traditionally used for creating replicas.

This provides a few primary benefits:

1. Does not require a platform migration to a DB provider like neon, allowing strong separation of production and development concerns. 2. Minimal impact on the production database while allowing clones to spin up in <6s, even at TB scale with copy-on-write

Security matters a lot with cloning production so we run a proxy layer to generate custom postgres URLs and route all connections to allow more granular access control to clones, prevent credential leak, and follow a split plane architecture to allow full data residency on your cloud through BYOC.

We also support anonymization through the ability to register SQL that runs on branches before they are returned. This has been used for PII redaction and branch modification.

Our goal is to make every data infrastructure platform “cloneable” in one place so agents can fully test the impact of their changes on production like data environments without risk.

Here's a demo of it: https://youtu.be/5S1kwPtiRU0

We’d love to understand how you work with coding agents on the DB and if you try Ardent (it's free to get started) what worked, what broke and what’s missing.


Comments

eugercekyesterday at 6:12 PM

If you use xfs (+`file_copy_method=CLONE`) you can do this with Postgres 18.

`CREATE DATABASE clankerdb TEMPLATE sourcedb STRATEGY=FILE_COPY;`.

But Ardent can be useful for many, because cloud providers uses heavily restricted Postgres. And many use Aurora, which doesn't event let configure the `log_line_prefix`.

Though if cloud providers add file_copy_method=CLONE compatible managed pg ...

ref: https://boringsql.com/posts/instant-database-clones/

show 2 replies
znnajdlayesterday at 5:13 PM

“Never impacts production data” is impossible to guarantee. Playing with real world data often has side effects outside of the database. For example if you store oauth tokens to external services in your DB (customer integrations) it’s easy to mess up your customers data through a bad API call (been there done that).

There is still value in carefully testing on your prod DB, but for that you could just easily maintain a read replica. I don’t see the need for a SaaS here.

show 2 replies
jedbergyesterday at 5:25 PM

Looks interesting, curious what your moat here is. What prevents Supabase/Neon from doing this? Actually don't they already do this? How does this differ from the branching Neon and Supabase already offer?

show 1 reply
danisazatoday at 6:49 AM

Congrats on the launch!

One note on the pricing: it would kind of bum me out to pay $250/month for $100/month in credit.

That feels like I'm losing $150/month.

Jinyibrucelitoday at 2:29 AM

I ran into this exact problem building browser automation agents that needed to test DB migrations. The real killer wasn't just getting a sandbox quickly, it was that reverting changes after a failed test would take forever with traditional backup/restore. One thing I'm curious about though - how do you handle agents that need to test against production data patterns but can't actually touch real user data? Do you have a synthetic data layer or is that on the user to solve?

show 1 reply
nilirlyesterday at 5:17 PM

Hi, site looks beautiful!

How does this compare to managing our own read-only replica with anonymized data?

show 2 replies
cphooveryesterday at 5:17 PM

How many people are giving an LLM Agent full read access to their production data? That seems nuts to me.

show 4 replies
clintonbtoday at 12:25 AM

Congrats on the launch! DB clones have been a game changer for my team, allowing us to build isolated workspaces for agents to do work ranging from optimizing queries/views to building UI/UX that works for the actually combinations of data we have.

We self-host DBLab since we had trouble getting Xata, Neon, and hosted DBLab configured.

fmajidyesterday at 5:46 PM

Doesn't look open-source. If you are interested in having a Neon or git-like branching for PostgreSQL experience, have a look at Xata, which is based on ZFS like Delphix was:

https://github.com/xataio/xata

show 1 reply
dou99today at 12:43 AM

The concept is cool but what value are you adding ontop of the Neon Twin infra it’s built on? It seems the same can be done just using Neon directly for half the cost?

show 1 reply
heocoitoday at 12:01 AM

[flagged]

Serhii-Setyesterday at 7:12 PM

[flagged]

galaSergeyesterday at 6:42 PM

[flagged]

kramit1288yesterday at 7:20 PM

[dead]