Мир баз данных долго жил без настоящего «линтинга» — автоматической проверки качества схем, индексов и настроек. Мы привыкли, что линтеры есть у кода, у Dockerfile, даже у YAML-конфигов, но базы данных оставались последним диким полем. И вот теперь пришёл pglinter — расширение для PostgreSQL, которое делает с базами то же, что flake8 делает с Python: ловит ошибки, плохие практики и потенциальные уязвимости ещё до того, как они взорвут продакшн.
⚙️ Как это устроено
pglinter написан на Rust с помощью фреймворка pgrx, что обеспечивает тесную интеграцию с самим PostgreSQL.
🧠 Он работает прямо внутри движка БД, без внешних скриптов и Python-обвязок, и анализирует всё — от структуры таблиц до конфигурации кластера.
📜 Проверки организованы по категориям:
- 🧱 B-series (Base) — общие проверки здоровья базы: отсутствующие первичные ключи, дубли индексов, небезопасный public schema.
- 🖥 C-series (Cluster) — ошибки конфигурации, например, избыточное потребление памяти или уязвимые записи в pg_hba.conf.
- 📊 T-series (Table) — таблицы без индексов, неиспользуемые индексы, неверные внешние ключи.
- 📁 S-series (Schema) — проблемы с правами доступа и публичными схемами.
🧪 Интеграция и применение
Одно из сильнейших решений pglinter — формат отчётов SARIF (тот же, что использует GitHub Code Scanning).
💡 Это значит, что вы можете встроить анализ базы прямо в CI/CD, и каждый pull request будет проверять не только код, но и SQL-схему.
Команды максимально просты:
CREATE EXTENSION pglinter;
SELECT pglinter.perform_base_check();
А если нужно зафиксировать результаты в файл:
SELECT pglinter.perform_base_check('/tmp/results.sarif');
Правила можно включать и выключать динамически:
SELECT pglinter.disable_rule('B004');
— и даже получать объяснение, почему правило сработало:
SELECT pglinter.explain_rule('C002');
🔐 Безопасность и DevOps-подход
pglinter особенно полезен там, где нет выделенного DBA.
В современных DBRE-реалиях (Database Reliability Engineering) разработчики и DevOps-команды часто управляют базами сами.
А это значит, что ошибки вроде “открытого public schema” или “MD5-аутентификации” (которая уже запрещена в PostgreSQL 18) могут остаться незамеченными.
pglinter ловит такие вещи на лету и позволяет строить профилактическое качество данных, а не реагировать на аварии.
💬 Моё мнение
pglinter — это не просто инструмент для проверки базы, а знак зрелости экосистемы PostgreSQL.
Раньше для анализа приходилось писать кастомные SQL-скрипты, сегодня — достаточно установить расширение.
Особенно впечатляет, что проект написан на Rust: значит, можно ожидать стабильности и высокой производительности даже на больших кластерах.
Я вижу в pglinter шаг к тому, чтобы базы данных стали частью DevSecOps-цепочки — когда инфраструктура, код и данные проверяются одной системой качества.
🔗 Источники
📘 Официальная документация pglinter
💡 pgrx — Rust SDK для PostgreSQL
📦 Формат SARIF на GitHub Docs
⚡ pglinter превращает PostgreSQL из просто надёжного движка в умного собеседника, который сам подскажет: “Кажется, у тебя лишний индекс и дырка в безопасности — исправь до релиза.”