CI Build Status License - MIT Status - Alpha


"Learn the rules like a pro, so you can break them like an artist."

— Picasso

IntegrateDB is a database sharing system. It provides integration primitives and data ownership and migration controls. Use it to integrate applications directly through a Postgres database.

Why would I want to do that?

"Most software architects that I respect take the view that integration databases should be avoided."

— Martin Fowler

Integration databases are typically regarded as a smell. They "don't scale" and either block changes or break apps. Instead, services are integrated using APIs and message-buses. This comes at a cost. Additional work to serialize, transfer, validate and map data through multiple layers. Operational complexity to deploy and coordinate those layers.

IntegrateDB takes a different approach. Rather than building extra layers to mitigate architectural concerns, it mitigates those concerns directly. This leads to faster development and simpler systems — fewer layers, less code and less plumbing.

How exactly does it work?

Note: IntegrateDB is currently alpha stage software. See the Known Issues for context.

Using IntegrateDB, applications explicitly declare the data shape (tables, columns, types) that they need access to.

IntegrateDB then:

  1. scopes database access credentials so that applications can only access data they declare
  2. validates DDL migrations to allow safe schema evolution without breaking data dependencies
  3. makes it easy to subscribe to and handle notifications when data is changed by another application

Example - integrate a reporting application

Imagine that you have a primary web application with a Postgres database and that you want to integrate a reporting system. Assume you've installed IntegrateDB and bootstrapped a root user. You then start by creating a Stakeholder representing your secondary reporting application:

curl -X POST -H "..." -d '{"name": "reporter"}' /api/v1/stakeholders

This creates a Postgres database user (reporter) with access scoped to its own private DDL schema (reporter.*) and returns the database user credentials in the response data:

  "data": {
    "credentials": {
      "username": "reporter", 
      "password": "... randomly generated ...",

Save the credentials (somewhere safe!) and provide them to your reporting application as the database user and password it should use to connect directly to the Postgres database.

Declare data dependencies

Now, say that your reporting application is interested in orders placed by customers. It can declare a claim on the relevant data by PUTing the following to /api/v1/stakeholders/:stakeholder_id/claims:

  "data": {
    "match": [
        "path": "public.orders",
        "fields": ["*"]
        "path": "public.customers",
        "fields": ["id", "user_id"]

With this configuration, the reporter application will be granted read access to the whole public.orders table and the id and user_id of the public.customers table. You will also soon be able to register for notifications when claimed data changes using an extension of the same syntax.

So that's how applications register as stakeholders, get dynamically scoped access credentials and declare data dependencies. Now for the payoff: migration control.

Migration control

IntegrateDB adds a function called integratedb_validate_migration() to your Postgres database. Call this at the end of your migration and it will prevent the migration from being applied if the DDL schema changes it's about to commit would break any declared data dependencies for any stakeholder application.

This works with whichever language or migration tool you prefer. For example, in raw SQL:

SELECT integratedb_validate_migration();

It's a smart function: it understands the difference between additive and destructive migrations and it allows you to configure options in order to explicitly facilitiate schema evolution.

Next steps

See the guides for more information:


IntegrateDB is released under the MIT license.


IntegrateDB is an Elixir application based on Phoenix and Broadway. The project is maintained on GitHub at by James Arthur (@thruflo).

Contributions, feedback and bug reports are welcome. Please raise an issue or start a PR to discuss. If you do contribute code, please write tests and run mix format.