so you don't even necessarily need Postgres when doing local dev for SpiceDB

although you certainly could use it if you have it already

--datastore-bootstrap-files strings                       bootstrap data yaml files to load

if you're interested in bootstrapping

Nice 🙏

the YAML files use the same format as downloaded from https://play.authzed.com

If you don't mind me asking one more question: Do folks generally use SpiceDB (or any other FGA system) as the single source of truth for all relational data? Or do people still have e.g. foreign keys in their RDBMS on the tables where they store their non-auth business data, e.g. to track members of a team or students of a class.

I don't mind at all! please don't hesitate to ask! 🙂

to answer your question: it really depends on the structure of data

often times users will store all the data in their RDBMS tables, and then only copy over the data necessary for SpiceDB

other times, users will keep the data for authz decisions solely in SpiceDB and metadata in their RDBMS

in my personal opinion: if you don't need certain data in your RDBMS, its not necessary to keep it there

as an example: you might have teams that have members, but the membership of teams is solely an authz detail, so you could keep that solely in SpiceDB and use a ReadRelationships call to grab it if you need it to display in the UI

but, say, the name of a team would be metadata stored in your RDBMS

Gotcha. I think I would lean towards duplicate relational data, just because it feels a bit more sane/secure to benefit from some of the DB features (e.g. FKs,

ON DELETE CASCADE

, etc.). There'd be the risk of data integrity issues if the relations are kept in multiple tables (or even separate DBs), but that might be acceptable. Edit: On second thought, the data integrity risks are probably a reason not to keep relations in two DBs/systems.

How do you deal with having different schema prefix in different environments?

if you mean while using Authzed.com, we typically recommend having it be a config value to your application

We are using besides authzed, auth0 as identity provider and try to use their user ids ("auth0|Xsu1soKNfF") as objectIds. The authzed api is fine to save relations with it, but I noticed the playground is throwing an error "Must be alphanumeric and at least three characters long". Will we have problems with it?

This might be a bug in the playground. If you could use the share button on the playground, that'd help a ton in figuring out if this is the case.

Yeah, that’s likely a client side playground check that is still too strict

It is the expected behaviour? If I delete relationships in the "test relationships" tab in the playground (play.authezd) and import them again, the relationships are not deleted.

Yep; you need to reexport to a new file or link

How can I delete a production tenant at authzed.com? Would it make sense to create an own channel for authzed.com ?

you can't delete them right now, but you can just empty them out and stop using them

is there a reason you want to delete it?

What does the dedicated product look like, as in what will I actually receive? Are we talking about a Terraform module or something else?

What does the dedicated product look

Hello Experts, I have played around with SpiceDB and its wonderful product. It has created a lot curiosity in my org. It make a lot of sense having zanzibar based solution as central authorization service for applications. There are some reporting solutions, they also want to leverage this solution, I was wondering if zanzibar based solution can be suitable for row level filtering or row level of security?

If the question is of granularity/scale, Zanzibar style solutions can. If you're looking for a deep integration with PostgreSQL RLS, then there is not anyway to my knowledge to make an API call from it. I have seen some folks build custom C extensions for foreign data wrappers, but once you explore FDW, you throw out the ability to use cloud hosted Postgres offerings.

Thanks, as these solutions are Reporting solutions, they have massive data, two concerns I see, 1. A lot of relationships data would be duplicated. 2. To produce a result of 100 records there will be 100 API calls and that's way too much.

In that case you may want to look into "ACL Filtering" support in our API with:

LookupResources

and

LookupSubjects