PostgreSQL может быть базой данных, источником событий, аналитическим источником или частью распределённого контура. Это четыре разные задачи

Если PostgreSQL является собственной базой приложения и контракт записи контролируется командой, SQL может быть естественным уровнем работы.

Поэтому доступ к БД сам по себе не даёт права считать её публичным API.

Мы различаем физическую возможность и архитектурно поддерживаемую границу.

• Если база принадлежит чужой прикладной системе, прямой INSERT или UPDATE может обойти

  валидацию; бизнес-логику; audit; очередь событий; расчёт зависимых данных.

«Мы только читаем» не означает «мы никак не влияем на production».

Всё это может влиять на операционную систему.

Цель — получить данные, не превращая BI в непредсказуемую production-нагрузку.

• Тяжёлый JOIN.

• Большой sequential scan.

• Долгая транзакция.

• Неудачный отчёт в рабочее время.

• Для аналитики AMPE оценивает

  read replica; выделенную витрину; ETL/ELT; CDC; ограниченные views; отдельного пользователя и resource controls.

PostgreSQL поддерживает logical replication по модели publication / subscription.

Она позволяет передавать изменения выбранных объектов и использовать логический уровень данных, а не поблочную физическую копию.

Но replication остаётся механизмом изменения данных, а не описанием бизнес-события.

• Это полезно, когда нужно

  передавать подмножество данных; строить отдельный consumer-контур; консолидировать данные; поддерживать определённые миграционные сценарии.

В таблице orders изменилось поле status.

CDC сообщает: row changed.

Бизнес может говорить: заказ подтверждён, отменён, отправлен на проверку или технически исправлен.

Если downstream важен именно смысл, лучше иметь явный event contract, чем заставлять потребителя каждый раз восстанавливать семантику из структуры таблиц.

AMPE использует CDC там, где нужен поток изменений данных, и domain events там, где нужен смысл действия.

PostgreSQL умеет отправлять уведомления между сессиями через LISTEN / NOTIFY.

Для локальных сценариев это может быть очень удобно.

Но если процесс требует гарантированного хранения сообщения, сложного retry, независимого consumer lag, масштабного fan-out и replay, мы не пытаемся превратить notification mechanism в Kafka или RabbitMQ.

Технология должна соответствовать гарантиям процесса.

Классическая проблема:

приложение успешно изменило данные в PostgreSQL;

после commit должно отправить сообщение;

процесс падает между этими двумя действиями.

База говорит, что операция состоялась.

Соседняя система о ней никогда не узнаёт.

Transactional outbox позволяет зафиксировать бизнес-изменение и намерение отправить событие внутри одной локальной транзакции, а публикацию выполнить отдельно.

Для событийных интеграций это часто принципиально важнее выбора конкретного broker.

Внешняя система повторила запрос.

Consumer повторно обработал event.

Batch был перезапущен после ошибки.

AMPE проектирует защиту от повторов до того, как они превратятся в дубли данных.

• Если одна операция должна иметь один бизнес-эффект, это правило должно быть отражено в модели

  unique key; external ID; operation ID; upsert policy; отдельная таблица обработки.

Колонку можно переименовать за секунду.

Но если её читает ETL, внешняя система, BI и CDC consumer, физическое изменение становится интеграционным релизом.

• Поэтому мы смотрим на schema evolution так же, как на API versioning

  что совместимо; кто consumer; какой переходный период; как обнаружить зависимость.

Foreign Data Wrapper позволяет PostgreSQL обращаться к внешним данным через табличную модель.

Для определённых задач это удобно.

Но latency, доступность удалённой системы, pushdown, транзакционные гарантии и ownership никуда не исчезают.

AMPE использует такой подход там, где виртуальный доступ действительно проще физической синхронизации, а не как способ скрыть архитектурные границы.

Принцип простой: интеграция должна уметь ровно то, ради чего она существует.

• Для integration account мы определяем

  какие schema; какие tables / views; read или write; какие операции; какие network boundaries; как хранятся credentials; как выполняется rotation; что попадает в audit.

Операционное приложение пишет транзакции в свою базу.

Нужные изменения попадают в outbox или CDC.

Интеграционный слой передаёт их дальше.

Аналитика работает с replica / DWH, а не бомбардирует production тяжёлыми запросами.

Внешние записи проходят через поддерживаемую прикладную границу там, где у данных есть бизнес-логика.

Schema changes контролируются как изменения контракта.

В итоге PostgreSQL остаётся сильной СУБД, а не превращается одновременно в API gateway, message broker и случайный integration bus.