Yeah, our release script is shipping RCs everywhere. Honestly, we wanted to see how it went and collect feedback from folks.

Sorry -- it should work now -- the pipeline also turns releases back into drafts sometimes after they're cut

Hi folks! I wanted to run this idea by you to see if it’s a feasible option. We have an app that stores its data in a mysql database. In order to use SpiceDB, we need to replicate some of the columns from this db into SpiceDB’s datastore. I wonder if it is possible, rather than replicating the data, run SpiceDB on top of this existing database, without changing the schema of the existing data, just by adding a (possibly readonly) datastore connector? Say we have a mapping that tells us relation “s r o” can be fetched through “select x, y from table t”. Note that the existing database doesn’t not do MVCC, but we “last_updated” timestamp on all row that could help. We may need to add some tables to store the schema and caveats but my question here is specifically about relations. Thoughts?

possible in theory

but the consistency guarantees will be an issue

you'll need to make sure if a row is updated there is a way to retrieve the "older" version of the row

This is the part I don't understand! What exactly do we lose if we always use the latest version? For how long do we need to keep the version history? Is that only for the duration of ztokens? Then if we don't have any history, will it be inconsistent just for the duration of ztokens?

it has to be kept for the duration of what we call the "quantization window" IF you're not using

at_exact_snapshot

consistency (which some people do, but many do not)

basically: when an API call is made to SpiceDB and

minimize_latency

is used, SpiceDB will pick a revision that is slightly older than "now", to efficiently use caches

but, in order to do that, it needs to be able to query at that older revision

which means there needs to be some way to ask the database for a view of the world at that older time

that window is usually 5-10s

but it is necessary

if you use

at_exact_snapshot

for anything, on the other hand, you need to be able to return data for it over a longer period

most default installs have that window as 24h

as a complete outsider, we've had pretty good luck treating the spicedb datastore as a black box

the more you try to interact with it at the database level the worse a time you're going to have

yeah, that's generally the recommendation

especially since we reserve the right to (and have) change the internal representation

it should also be noted that this may be possible if you use something like CRDB, which does provide "at specific time" querying

Is there a document that explain the consistency model in depth? I want to know a bit about the internals as well. Or I just need to read the source?

there is an overview one here: https://authzed.com/docs/reference/api-consistency

but as for internals, your best bet is to ask questions here (or read the consistency and datastore code, but there is a lot there)

I can't manage to start spicedb against postgres on azure because there is a

SELECT unique_id FROM metadata

query for the postgres datastore.

metadata

doesn't seem to be a standard builtin table and it doesn't exist in azure's postgres offering (neither in pg v13 nor v14). Do you have any workarounds in mind?

Hm it seems this query is used for telemetry. Side stepped it by disabling telemetry (

telemetry-endpoint=""

) for now.

actually it seems this table is later created by spicedb itself. Not clear what caused that ordering issue there.

I managed to start a local spicedb against an azure managed postgres but I fail to create a spicedb cluster though the operator and connect it to the same postgres instance. OTOH, I have succeeded creating clusters with the memory backend. What would be the best way to debug the spicedb-operator + clusters against postgres? I can't find any failed pods to see their logs and the spicedb-operator logs don't include anything super useful about failure causes.

I think the problem was that I was setting

datastoreConnUri

under

SpiceDBCluster

's

spec.config

, while the correct one is

datastore_uri

under `Secret`'s

stringData

. I should have checked the CRDB example earlier!

yeah:

migrate

has to be run first

and if the operator doesn't have the correct URI to do so, SpiceDB will fail to start