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?
Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
31–40 of 61 posts
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#32If 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…
Oh nice, the `/var` part of my workstation is a dedicated nvme drive and it's coincidentally formatted as xfs.
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#33Looks 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?
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 branching natively and autoscaling compute but you make certain performance tradeoffs. A lot of the folks we've talked to that use RDS or Planetscale are reliant on things like query laten…
You’re literally using Neon? lol
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#34If 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…
A little slow but on Aurora you can attach then promote read replicas. Iirc that's around 20 minutes but I haven't tested recently.
I'd think you could also setup logical rep to a VM then snapshot and clone the storage which is generally pretty fast.
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#35The 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?
Sounds like thats all they’re doing.
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#36If 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…
A little slow but on Aurora you can attach then promote read replicas. Iirc that's around 20 minutes but I haven't tested recently. I'd think you could also setup logical rep to a VM then snapshot and clone the storage which is generally pretty fast.
You can create a new instance directly on AWS aurora. Takes less than 20 minutes!
aws rds restore-db-cluster-to-point-in-time \
--source-db-cluster-identifier \
--db-cluster-identifier \
--restore-type copy-on-write \
--use-latest-restorable-time \
--db-subnet-group-name \
--vpc-security-group-ids \
--serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=16Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#37I 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?
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#38I 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 ha…
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 can retain production shapes but manipulate the data however you want to make it safe
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#39Congrats 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.
Re: Launch HN: Ardent (YC P26) – Postgres sandboxes in seconds with zero migration
#40“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 maintai…
[flagged]