things i've explored so far include: • adding writes to keto in application code alongside writes to the database • using postgres triggers to push messages that describe changes onto a message queue, and handling the messages by writing to keto • writing a logical replication client for postgres that maps changes onto writes to keto all of these have undesirable characteristics. the first two cannot actually guarantee consistency in all reasonable cases. the third has stronger guarantees but it is both difficult to do and couples the synchronization use case to the storage technology. i feel like i'm chasing something unattainable and maybe i would be better off just seeing what other folks have had success with. thank you!

Maybe you don't want to replicate the data in the first place but have Keto as the single source of truth? Or are you doing some fancy join queries that need that

parent_id

?

no fancy joins, just regular joins.

File

and

Folder

are tables in a relational database. developers are not going to accept a solution where they have to make requests to a permissions service in order to perform ordinary relational joins

sorry, somehow overlooked your answers I guess the eventual consistent approach will be the most robust as well. Maybe you can detect edge cases where updates did not propagate yet and force the propagation, then those edge case requests would just take longer, instead of returning the wrong result.

oh that's interesting. good suggestion, we'll look into it. thank you!