# IntegrateDB - Database sharing toolkit for Postgres

**URL:** <https://forum.elixirforum.com/t/integratedb-database-sharing-toolkit-for-postgres/37148>\
**Category:** Discussions\
**Tags:** phoenix, postgres, integration, liveview, broadway\
**Created:** [January 28, 2021, 2:11pm UTC](https://forum.elixirforum.com/t/integratedb-database-sharing-toolkit-for-postgres/37148 "2021-01-28T14:11:58Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![thruflo](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/thruflo/32/21652_2.png) [@thruflo](https://forum.elixirforum.com/u/thruflo)\
**Post date:** [February 2, 2021, 7:53am UTC](https://forum.elixirforum.com/t/integratedb-database-sharing-toolkit-for-postgres/37148/18 "2021-02-02T07:53:13Z")

</div>

@eteeselink thanks for the feedback and for digging into the code 🙂

You are right that at the moment it’s consuming every replication update and that this isn’t necessary. Let me try and explain!

What I’d conceived of initially was to combine the data claims with the ability to use the same machinery to configure notifications, as per [usage.html#notifications](https://hexdocs.pm/integratedb/usage.html#notifications). So the intention is to consume the logical replication feed and then “forward on” updates that a secondary app has registered for over web hook / socket / queue / etc. Now, I haven’t got round to implementing the event handling part of this yet and it’s on my todo list when implementing to restrict the publication feed to stream updates to just the registered tables.

What I have implemented atm is using the logical replication machinery as a way to tell IntegrateDB to re-sync the data access claims after a migration. User specification data like `fields: ["*"]` is expanded to snapshot the actual columns that match the spec when saving data access claims. This needs to be re-done whenever the DDL changes, which means somehow triggering the process. Right now, I have an `integrated_sync()` function in the db that inserts a new record to the integratedb.sync table and then the only thing the replication consumer actually does atm (as per [replication.ex#L56-L66](https://github.com/integratedb/integrate/blob/main/lib/integrate/)) is watch for these changes.

This could and should be locked down – the publication feed only needs the sync table at the moment. (In fact, I just pushed a temporary fix: [replication: limit publication to just the sync table for now. · integratedb/integrate@0b4a7a3 · GitHub](https://github.com/integratedb/integrate/commit/0b4a7a38d014e5ae973a1fa807c137834dfdf9cb)).

However, following some of the previous feedback in this thread, I’m thinking a more comprehensive solution is to separate out the “ops client” (which as you say can be passive and just needs to create db accounts which can only access those fields they claim access to, and then verify that DB migrations don’t violate those claims) from the notification service, which needs to be a running application to consume and forward on the events. This would mean that you wouldn’t need to enable replication at all unless you want to run the notification service.

The wrinkle is that I still need to expand spec data into claims somehow, which maybe means moving some logic into the database. That’s maybe a better solution anyway as it then could be done transactionally as part of the migration.

Hope that makes sense and thanks again for pointing this out!

---

_[View the full topic](https://forum.elixirforum.com/t/integratedb-database-sharing-toolkit-for-postgres/37148)._