[nescioquid]

While they quickly acknowledge that integrating by means of a database is widely regarded as an anti-pattern, the rest of the article doesn't really address why this wouldn't be an anti-pattern, other than to pretend that the major reasons for avoiding this pattern are deployment complexity and furnishing multi-region services.

> A customer pattern we see solves this problem, and it’s the integration database pattern. This pattern went out of style in the 90s along with Oracle servers in the closet and dedicated DBAs, but with technological advances like scalable multi-region transactions and serverless computing resources, its utility has returned.

Considering they are flogging a product, this feels especially dishonest to me.

[thruflo22]

Not related to the original article but I had a go at articulating the rationale here: https://hexdocs.pm/integratedb/intro.html

(This project isn’t ready for prime time but it was a sketch of an approach to mitigating the downsides of integrating through the database, in order to unlock the upsides).

[mumblemumble]

Also not the author, but I have seen some success here when the database is used as another way to build a service with an API, and not just a simple data store. What that means in practice is that applications interact exclusively through stored procedures, which serve as a sort of RPC API.

The big downside of this approach are that the human factors are tricky nowadays. Developers expect to be allowed to poke at the tables directly, and don't necessarily take kindly to alternative ways of framing things. Especially if they've been raised on a diet of code-first object relational mapping. And there's not really a great way to enforce this boundary, because, unlike HTTP, an ODBC session will generally let you pretty much anything you want to the remote service's implementation details.