Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tryardent.com

Post reply on HN
Print view View original

21–30 of 61 posts

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

#23

Post by vc289 »

jedberg wrote: post #14
cphoover wrote: post #13

Earlier quoted context omitted.

Jedberg... Wow an internet legend replied to me! > > I'm much more worried about people who give full write access to their agents! But at least this solves that problem. Yeah it goes without saying that write access would be crazy... But, it seems like people don't really care about the fact that they are just giving their private data to companies like Anthropic, OpenAI and Google. > Branch anonymization Branches d…

> Jedberg... Wow an internet legend replied to me! Hey, I put on my pants the same way you do: by having my staff hold them up while I jump into them. > But, it seems like people don't really care about the fact that they are just giving their private data to companies like Anthropic/Open AI and Google. This isn't quite as risky as it seems. All of them have a TOS that says if you pay them enough money they won't tra…

>> 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 level policy objects so we can do enforcement of any kind on the branches before they're ever actually handed to users. This would be things like access control + defined anonymization rules. The broader hope with this class of objects/policies is they can serve as enforcement barriers and essentially allow scoped access at the org level across branches.

The proxy we run in the middle also helps a lot here. Since the URL is minted by our control plane and is not the "real" DB url we can authenticate each user from the URL they're using and enforce RBAC controls.

for example:

User 1's API key is 1234

The CLI can auto-construct urls like: postgresql://{APIKEY}:{ANYTHING}@{IDENTIFIER}--postgres.routing.tryardent.com:5432/DB_NAME?{params}

Your API key is something that can be scoped per user

This is an off the cuff example but essentially we have a way of knowing who is calling the host and thus can enforce if APIKEY = You can't access this DB based on whatever rules.

Curious to understand what additional pieces would be helpful here because this is 100% very important to get right.

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

#24

Post by polskibus »

fmajid wrote: post #9

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

Would such approach work for MS SQL?

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

#25

Post by mnahkies »

eugercek wrote: post #15

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…

I wanted to try doing something similar to this in our dev environment (think shared dev database but per branch clones), but this limitation seemed tricky to accept:

> The source database can't have any active connections during cloning.

I wouldn't mind some lock contention, but having to kill all connections seemed a bit harsh

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

#26

Post by the__alchemist »

eugercek wrote: post #15

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…

Here's how I do it with Heroku. Are there some cloud services that don't have an equivalent?

  heroku pg:backups:capture --app x
  heroku pg:backups:download --app x
  pg_restore --verbose --clean --no-acl --no-owner -h localhost -U postgres -d y local_db_for_robots_etc.dump
This takes more than 6 seconds. I'm curious how they achieved that for arbitrary DBs!

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

#28

Post by vc289 »

the__alchemist wrote: post #26
eugercek wrote: post #15

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…

Here's how I do it with Heroku. Are there some cloud services that don't have an equivalent? heroku pg:backups:capture --app x heroku pg:backups:download --app x pg_restore --verbose --clean --no-acl --no-owner -h localhost -U postgres -d y local_db_for_robots_etc.dump This takes more than 6 seconds. I'm curious how they achieved that for arbitrary DBs!

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 serves as a read replica. That DB is the one that branches but since it mirrors the original DB you get effective clones

By doing this we get a lot more control over what we can do to create the clones. The read replica clones using copy on write + isolated autoscaling compute to clone in 6s. We use neon to do this since we think they've implemented those two properties well.

Since it's default postgres logical replication + DDL triggers you can technically point it at any "branching enabled" db on the other end in order to achieve the same effect

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

#29

Post by clintonb »

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.

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

#30

Post by fmajid »

polskibus wrote: post #24
fmajid wrote: post #9

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

Would such approach work for MS SQL?

There's no reason why it shouldn't, Delphix primarily targeted Oracle, but there is of course not as much open-source enthusiasm for supporting a proprietary database as an open-source one.
Post reply on HN