> this would still leave the problem where each transactions causes two deletes and two inserts Indeed! You might be interested in the '6.5 Materialization Con

> this would still leave the problem where each transactions causes two deletes and two inserts Indeed! You might be interested in the '6.5 Materialization Controls' section of this paper: https://arxiv.org/pdf/1905.12133.pdf https://arxiv.org/pdf/1905.12133.pdf They intend to add these extensions: SELECT ... EMIT STREAM AFTER DELAY INTERVAL '6' MINUTES ; -- to fix the output multiplication you mention SELECT ... EMIT STREAM AFTER WATERMARK ; -- this should fix the two deletes and two inserts I don't know if this is still in active development, though. There has been no news since the paper got published 2 years ago. > It doesn't seem like there is window you could set that would be guaranteed to connect them? No there isn't. But I'm quite confident having a transaction-centric approach can be obtained in SQL. Your use case is perfect for illustrating the problem, still. I'd try something like: CREATE VIEW credits AS SELECT to_account AS account, sum(amount) AS credits, last_value(id) AS updating_tx FROM transactions GROUP BY to_account; And then try to join credits and debits together by updating_tx. No idea on how to check that accounts don't go negative, though.