vc289

5 ms·

1.
by vc289 4mo ago
Totally makes sense. We do offer a pure PAYG tier (starter) that scales completely dynamically to workload But seems like this may be less about the absolute price but more about the way the 100/month of credit feels? What do you think
2.
by vc289 4mo ago
It does clone the data. It uses copy on write to clone so data size won't slow it down since it's a metadata operation instead of actual data movement It clones the entire DB so it's not quite 6s per TB but actually the entir
3.
by vc289 4mo ago
We have ways to scrub PII/manipulate the data on the clone per branch. It's called branch hooks and lets you register SQL to be run against the branch after it's created but before it's handed to you (or an agent) So you
4.
by vc289 4mo ago
We've got docs on how we did it :) https://docs.tryardent.com/architecture But essentially we get around the restrictions of the original DB by replicating into a different postgres compatible DB that essentially serve
5.
by vc289 4mo ago
>> I'm sure it will cause trouble if you don't also bring along with the copies the internal controls around access logging Yep! Agreed. We've tried to combat this with the "branch_hooks" being team/org l
6.
by vc289 4mo ago
One of the main things people use us for is ease of testing writes on a per dev/agent basis which would be difficult on a read replica! On the real world data impact I absolutely agree. We added something called "branch hooks&quot
7.
by vc289 4mo ago
A true read replica won't let you write! So if you need to test something like a backfill and see if anything goes wrong you wouldn't be able to quite as easily. We'd let you instantly clone prod + user defined auto-anonymiza
8.
by vc289 4mo ago
We enable branching on any postgres DB through our architecture. So if you're on RDS, Planetscale, etc you can keep your DB where it is but also get the ability to branch with a full clone of the DB. Neon does support copy on write bra
9.
Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration(tryardent.com)
99 points by vc289 4mo ago|52 comments
10.
by vc289 5mo ago
It's fundamentally impossible to stop an agent from performing a destructive action through instruction Llms are just too creative. They will explore the search space of probable paths to get to their answer. There's no way you ca
11.
by vc289 8mo ago
Not true for the db layer :) Look into copy on write branching. We built this natively into our AI Data Engineer ( https://tryardent.com ) so it could make modifications to databases with 0 blast radius pretty much because yes it&
12.
by vc289 8mo ago
If you're on postgres happy to have you try what we built at Ardent ( https://tryardent.com ). Our agent makes instant copies of your db for the agent to operate on so there's 0 risk for your db to ever get wiped. email
13.
by vc289 8mo ago
Also, lots of people here have said to give it fine grained, read only access. This works if you want a copilot experience but doesn't allow you to fully let the agent do write-style things like model data or anything else. COW branchi
14.
by vc289 8mo ago
We solved this exact thing for the database layer (postgres for now) with https://tryardent.com You can't trust any agent to be perfect with a real db so unless you find an infra level way to isolate it, you can't get
15.
Show HN: Ardent – An AI Data Engineer(ardentai.io)
9 points by vc289 2y ago|3 comments
16.
by vc289 2y ago
It would be interesting to consider branchable DBs as part of the migration cycle, especially for forward and backwards time skips. While not dealing with that kind of scale yet, our application (An AI Data Engineer that has done migration
17.
by vc289 2y ago
I'm building an AI Data Engineer @ Ardent AI. It's an autonomous AI Agent that can perform data transformations in your databases (mongodb,postgres,supabase for now) from plain english queries It drops directly into your stack, no