Hey there,
I have an application ecosystem utilizing the latest from Tanstack DB w/ the Electric Sync Engine. The sync engine utilizes the txid for write operations for syncing between
Web/Mobile <--> Replicated DB <--> Remote/Docker instance.
I've seen others utilizing ORMS like drizzle with some success, but without it I added txid columns onto my tables and have a trigger function to set the txid on write operations. This is working but suboptimal, as it introduces potentially unneeded boilerplate/management on my end.
Is there a recommended Supabase-native way to access the transaction id from inserts/updates without requiring RPC calls or per-table triggers?
Or alternatively: is there any reason Supabase avoids exposing txid metadata by default (security/replication concerns/etc)?
Curious if this is a known limitation, or if I’m missing an easier approach.
The user is seeking a Supabase-native method to access transaction IDs (txid) for syncing operations without using RPC calls or table triggers. They are currently using a custom solution with triggers but find it suboptimal. They inquire if there's a reason Supabase doesn't expose txid metadata by default and if there's a better approach.
I've never seen any real discussion from Supabase on this other than a performance doc mentioning what they are used for. We have one user helper here (@1086143228652306506) that is really good with Postgres that might have more to offer. I would assume though nothing supabase has added to what default postgres provides. You could also try their support.
Ok thx, I may just need to adopt an ORM for this... we shall see what @1086143228652306506 has to say on the subject, appreciate the response
for context
https://tanstack.com/db/latest/docs/collections/electric-collection#1-using-txid-recommended
the above is the system in which utilizes the txid