vc289

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 could be better? The intention of the 250/month scale tier was intended for companies scaling up that want BYOC for data residency etc. etc. and give them enough to test things internally without worrying about an overage bill before running it directly on prod but this might be able to be implemented better.

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 entire thing takes <6s independent of size

Probably something to adjust on the site to make it clearer!

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

>> 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.

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" which essentially let you define SQL to run against the branch before it's returned

This lets you essentially anonymize and modify the branch to scrub unintended external side effects.

It's something that we're still working on though and trying to design the right abstractions around because we want to get that part right.

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-anonymization so you can test writes. The architecture also somewhat takes the place of an existing read replica if you want to use it like that to make it more cost efficient.

Also since we're using copy on write for the clones they're incredibly storage efficient and the autoscaling compute helps minimize cost on clones by minimizing excess compute uptime

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 latencies supported by that platform's specific architecture but also want the ability to test on branches. We let you get the best of both worlds (branch but leave your DB where it is and freely choose your production environment based on prod concerns)

Supabase does have branching but they do not branch the data so you can't test any interactions that rely on the data. You can restore from backup as an option but this slows down based on data size since you're actually moving data as opposed to copy on write.

Longer term we want to be the place you branch all your data infra. So expanding to S3, Snowflake, MySQL etc.

For now though we're focusing on just postgres and getting it right!

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 can patch all paths

We had to build isolation at the infra level (literally clone the DB) to make it safe enough otherwise there was no way we wouldn't randomly see the DB get deleted at some point

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 branching removes that restriction