Data Science. SQL hub

Postgres: best practices для AI-агентов (и почему это важно) Supabase выпустили Postgres Best Practices - набор правил/“скиллов” для AI coding agents (Claude Code, Cursor, Copilot и т.д.), чтобы они писали не просто рабочий SQL, а нормальный продовый Postgres. Потому что классическая проблема такая: агент сгенерит “правильный” запрос, тесты пройдут, а через 2 недели это превратится в: - медленные JOIN’ы - seq scan на миллионы строк - взрыв коннектов - блокировки - RLS, которая внезапно тормозит всё Что внутри “Postgres Best Practices” Это структурированный набор правил по 8 темам (от самых критичных к менее критичным): - Query Performance (Critical) - как писать запросы, чтобы не убивать базу - Connection Management (Critical) - пулы, лимиты, правильная работа с коннектами - Schema Design (High) - индексы, типы, ключи, нормальные схемы - Concurrency & Locking (Medium-High) - как не словить дедлоки и долгие locks - Security & RLS (Medium-High) - RLS без боли и сюрпризов - Data Access Patterns (Medium) - как правильно читать/писать данные в приложении - Monitoring & Diagnostics (Low-Medium) - что мониторить и как дебажить - Advanced Features (Low) - продвинутые приёмы Самое полезное: это не “статья”, а готовый набор инструкций, который агент может автоматически применять, когда он: - пишет SQL - проектирует схему - предлагает индексы - оптимизирует запросы - настраивает RLS / connection pooling То есть агент начинает думать ближе к DBA, а не как генератор SQL. https://supabase.com/blog/postgres-best-practices-for-ai-agents

Мошенники использовали данные ФССП для незаконного взыскания долга: разбор схемы🧐 Специалисты вскрыли изощренную схему, где преступники, используя технологии социальной инженерии, представились судебными приставами. Цель — запугать жертву и вынудить к «срочному» платежу. В ходе расследования был детально разобран случай, когда сотрудник компании-клиента получил SMS от «пристава» с угрозой немедленного ареста имущества за долг родственницы. Злоумышленники, владея информацией о реальных сотрудниках ФССП и процедурах, создали психологическое давление. Жертве передавалась ссылка на оплату, ведущая на поддомен сайта МФО. Эксперты Securizor провели цифровую верификацию, оперативно выявили предлог совместно с настоящими приставами и установили связь мошенников с коллекторами. Данный кейс — не просто история о мошенничестве. Он демонстрирует важность социальной инженерии как инструмента кибератаки и необходимость проактивного аудита информационной безопасности для сотрудников. ❗️Читайте полный разбор расследования по ссылке Реклама. ООО "Секьюризор", ОРГН 1247700543694 Erid: 2W5zFFzBkTs

🖥 Хотите освоить SQL и PostgreSQL без курсов и подписок? Есть мощный бесплатный репозиторий, который проведёт вас от нуля до уверенного уровня всего за пару месяцев. Это полноценный учебник + практика в одном месте. Что внутри: - База без воды SELECT, WHERE, ORDER BY, LIMIT, условия и логика запросов - Продвинутые темы агрегатные функции, GROUP BY, HAVING, подзапросы, JOIN’ы - Много практики упражнения и задачи, чтобы довести работу с БД до автоматизма - Подробные объяснения материал подойдёт даже тем, кто никогда не работал с базами данных Почему это полезно: SQL — один из самых универсальных навыков в IT. Он нужен разработчикам, аналитикам, data-инженерам и всем, кто работает с данными. Этот репозиторий даёт именно то, что нужно для реальной работы: - понимание, как устроены запросы - уверенную работу с данными - базу для перехода к аналитике или backend-разработке GitHub: https://github.com/dwyl/learn-postgresql

🖥 Новый курс на Stepik - PostgreSQL для разработчиков: от основ к созданию API Здесь на пальцах объясняют не только как писать SQL-запросы, а строить настоящие backend-сервисы с базой данных как у профи. В этом курсе ты шаг за шагом создашь REST API на FastAPI + PostgreSQL: от установки среды и первых таблиц - до масштабируемого приложения с безопасностью и CRUD-операциями. 🔹 На практике разберете: • SQL-запросы, фильтры, агрегаты и подзапросы • Связи между таблицами и нормализацию БД • Взаимодействие Python и PostgreSQL • Реализацию REST API и подключение базы • Оптимизацию и разбор реальных задач с собеседований ⚡ После курса у вас будет свой работающий API-проект и реальные навыки работы с PostgreSQL в продакшене. 🎁 Торопись пока действует скидка в честь нвого года! 🚀 Прокачаю свои знания: https://stepik.org/course/255542/

🚀 MongoDB Memory Leak Exploit (CVE-2025-14847) Прототип эксплойта для уязвимости в MongoDB, позволяющий неаутентифицированным злоумышленникам утекать конфиденциальную память сервера. Уязвимость связана с некорректной обработкой длины данных при декомпрессии, что приводит к утечке неинициализированной памяти. 🚀 Основные моменты: - Позволяет утекать данные из памяти MongoDB. - Использует уязвимость zlib для создания поддельных BSON документов. - Может раскрывать внутренние логи и конфигурацию MongoDB. - Включает Docker Compose для тестирования уязвимости. 📌 GitHub: https://github.com/joe-desimone/mongobleed

🚨 Когда пайплайнов становится больше одного, ручные скрипты и cron перестают работать. Ошибки теряются, зависимости ломаются, контроль исчезает. 🚀 На открытом вебинаре разберём оркестрацию data-pipelines с помощью Prefect — современного инструмента для управления ETL-процессами, мониторинга и автоматизации. Покажем, как устроен оркестратор изнутри, чем Prefect отличается от классических решений и в каких сценариях он действительно оправдан. Вы увидите создание flow, настройку расписаний, деплой и управление задачами через Prefect UI. 🦾 После урока у вас будет чёткое понимание, как внедрять Prefect в существующую инфраструктуру, контролировать выполнение пайплайнов и масштабировать процессы без хаоса. 📅Встречаемся 18 февраля в 18:00 МСК в преддверии старта курса «Data Engineer». Регистрация открыта: https://otus.pw/8e01/?erid=2W5zFHfwisS Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

📚 SQL Чек-лист: защита базы данных от взлома Закрой базу от интернета - БД не должна слушать 0.0.0.0 без нужды. Открывай доступ только из подсети приложения (VPC, private network). Используй принцип наименьших прав - отдельный пользователь на каждое приложение, только нужные SELECT/INSERT/UPDATE, без SUPER/OWNER. Пароли и секреты - длинные, уникальные, храни в Secret Manager/.env вне репозитория, регулярно ротируй. Шифрование - включи TLS для соединений, шифруй бэкапы и диски (at-rest). Обновления - патчи БД и ОС ставь регулярно, отключай лишние расширения и фичи. Защита от SQL-инъекций - только параметризованные запросы, никакой конкатенации строк в SQL. Логи и аудит - включи логирование входов, ошибок, подозрительных запросов, алерты на “подбор паролей”. Бэкапы + проверка восстановления - делай бэкапы и обязательно тестируй restore, иначе это не бэкап. Ограничь опасные команды - запрети DROP/ALTER в проде для app-юзеров, разнеси миграции и рантайм доступ. Rate limiting и защита периметра - firewall/SG, fail2ban/pgbouncer limits, VPN/bastion для админки.

Postgres hardening (quick example)

ufw allow from 10.0.0.0/8 to any port 5432
psql -c "CREATE ROLE app LOGIN PASSWORD 'STRONG';"
psql -c "REVOKE ALL ON DATABASE prod FROM PUBLIC;"
psql -c "GRANT CONNECT ON DATABASE prod TO app;"
psql -c "ALTER SYSTEM SET ssl=on;"
psql -c "ALTER SYSTEM SET log_connections=on;"
psql -c "ALTER SYSTEM SET password_encryption='scram-sha-256';"
systemctl reload postgresql

🖥 Большинство “парсеров” умирают через 2 дня. Ты научишься делать те, которые живут в проде. Это не про BeautifulSoup ради галочки. Это про системы сбора данных, которые: • не падают от мелких правок на сайте • собирают данные в разы быстрее • обновляют всё сами по расписанию • обходят ограничения и баны • выглядят как сервис, а не хаос из файлов Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться. В итоге ты сможешь: • забирать данные для своих проектов • автоматизировать чужую рутину • делать инструменты для аналитики • брать коммерческие заказы на сбор данных Это навык, который напрямую превращается в деньги. Не “знаю Python”, а умею добывать данные из интернета профессионально. 🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

🍰 Polars v1.37.0: min/max строки по другой колонке - в одну строку Раньше, чтобы найти строку с минимальным/максимальным значением по другой колонке, приходилось: - сортировать - группировать - писать сложные фильтры Теперь в Polars v1.37.0 всё проще. Добавили методы выражений: ✅ min_by ✅ max_by Они позволяют находить min/max значения по любой колонке одной понятной строкой кода - без лишней магии и многошаговых костылей. Пример логики: "дай продукт с максимальными продажами внутри каждой категории" - теперь делается красиво и читаемо. Обновление: pip install -U polars

💨 Тормозят SQL-запросы и дашборды? Освободите своё время и нервы! Устали каждый раз пить кофе, пока выполняется запрос? Раздражает, когда дашборд висит на последнем проценте загрузки? Пора это прекратить! Приглашаем вас на практический вебинар «Аналитика без тормозов» 11 февраля в 19:00. Мы разберем, как радикально ускорить вашу работу. На вебинаре вы:

🔸 Узнаете об эффективных подходах — от тактических SQL-приёмов до стратегических архитектурных решений. 🔸 Разберёте конкретные методы, применимые к любой СУБД, и тонкие нюансы оптимизации. 🔸 Получите готовый набор фишек для ускорения запросов и витрин уже на следующий день.

Проведет вебинар Георгий Семенов, руководитель команды Analytics Engineering в Яндексе. Его опыт (VK, Wildberries, ЦУМ, ВТБ) и 14 лет в управлении IT-проектами — это концентрат практических знаний без воды. Все участники получат в подарок практический урок из курса SQL Pro про оптимизацию запросов — навсегда. Ускорьте свою аналитику одним кликом: simulative.ru/web-sql-speedup

⚡️ Масштабирование до 1 000 000 пользователей - практичный подход с PostgreSQL Автор работал над системой, которая выросла с нуля до более чем миллиона пользователей. Без сложных модных архитектур на старте и без преждевременного оверинжиниринга. Только последовательная эволюция под реальные нагрузки. В начале всё было максимально просто: Одно приложение - одна база данных. И этого было достаточно. Проблемы появились не в коде. Узким местом стала база данных. Архитектура развивалась шаг за шагом, решая конкретные проблемы по мере их появления. 1️⃣ Старт - один основной инстанс Использовался один primary-инстанс PostgreSQL. Минимум инфраструктуры, низкие расходы и полный фокус на продукте. Главная мысль этого этапа - не строить "архитектуру уровня Netflix" для проекта с десятками пользователей. 2️⃣ Разделение чтений - Read Replicas Когда резко вырос read-трафик: - Primary обрабатывал только записи - Реплики обрабатывали SELECT-запросы - Балансировщик распределял чтения Кодовая база почти не менялась - менялась маршрутизация трафика. Результат - база перестала быть узким местом из-за чтений. 3️⃣ Проблема соединений - добавление pgBouncer При росте числа пользователей упёрлись не в CPU, а в количество соединений. Каждое соединение к базе - это память и ресурсы. Тысячи коннектов начали "душить" систему. Решение - connection pooling через pgBouncer: - Меньше реальных соединений к БД - Выше пропускная способность - Меньше сбоев под нагрузкой 4️⃣ Масштабирование через кэш Чтобы выдержать 1M+ пользователей, стало критично не обращаться к базе за каждым запросом. Добавили Redis как слой кэширования: - Часто используемые данные отдавались из кэша - База перестала быть единственной точкой нагрузки - Задержки заметно снизились Именно на этом этапе начинается настоящее масштабирование. Главный урок На каждом этапе решалась текущая проблема, а не гипотетическая задача будущего. | Проблема | Решение | |---------|---------| | Много чтений | Read Replicas | | Слишком много соединений | Пул соединений | | База перегружена запросами | Кэш | | Сложная инфраструктура | Не добавлялась без реальной необходимости | Приложение существует, чтобы поддерживать бизнес. Если бизнес-модель не работает, никакое масштабирование не спасёт. Масштабирование - это не про технологии ради технологий. Это про внедрение решений в тот момент, когда они действительно нужны. milanjovanovic.tech/blog/scaling-monoliths-a-practical-guide-for-growing-systems

Теперь можно ничем не беспокоиться

Не двигайтесь: вы в ИИ-кадре Этот бот создает фото для соцсетей в футуристичном стиле. Его можно поставить на аватарку, особенно если идете на t-sync conf. Конференция от Группы «Т-Технологии» для опытных инженеров впервые пройдет в Москве 7 февраля. Попробовать бота можно здесь. А узнать больше о t-sync conf и зарегистрироваться — здесь

🧠 Вы когда-нибудь рисовал схему БД в тертрадке, а потом часами переносил всё в SQL? Есть способ быстрее - из диаграммы сразу в продакшен-код. DrawDB превращает твою ER-диаграмму в SQL: просто перетаскиваешь таблицы на канвас, связываешь их визуально - и экспортируешь готовый SQL под нужную СУБД. Что умеет: - Рисуешь таблицы и связи на визуальном холсте - Экспортируешь production-ready SQL для: MySQL, PostgreSQL, SQLite, MariaDB, MSSQL, Oracle - Без аккаунта и подписок - Можно мгновенно шарить диаграммы команде И да - 100% бесплатно и open-source 🔥 📦 Репозиторий: https://github.com/drawdb-io/drawdb

🖥 Большинство “парсеров” умирают через 2 дня. Ты научишься делать те, которые живут в проде. Это не про BeautifulSoup ради галочки. Это про системы сбора данных, которые: • не падают от мелких правок на сайте • собирают данные в разы быстрее • обновляют всё сами по расписанию • обходят ограничения и баны • выглядят как сервис, а не хаос из файлов Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться. В итоге ты сможешь: • забирать данные для своих проектов • автоматизировать чужую рутину • делать инструменты для аналитики • брать коммерческие заказы на сбор данных Это навык, который напрямую превращается в деньги. Не “знаю Python”, а умею добывать данные из интернета профессионально. 🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

🐘 Появился MCP-сервер и плагин для Claude, который буквально «ставит на место» ИИ-ассистентов при работе с PostgreSQL. Главная боль с нейросетями в SQL - они любят: писать устаревшие конструкции, игнорировать индексы, путаться в версиях PostgreSQL и галлюцинировать оптимизации, которых не существует. Этот инструмент решает проблему радикально: ассистент больше не фантазирует — он опирается на официальные знания и готовые практики. Что он даёт агентам (Claude Code, Cursor и др.): — Поиск ответов прямо в официальной документации PostgreSQL с учетом версии (12, 14, 16+). Не абстрактный «SQL из интернета», а то, что реально работает в твоей версии. — База знаний по экосистеме. Уже встроена документация по TimescaleDB, дальше — другие расширения. — Готовые проверенные паттерны: проектирование схем, выбор типов данных, ограничения, индексы, перформанс. Агент использует шаблоны лучших практик вместо галлюцинаций. — Работает как публичный MCP-сервер для разных инструментов или как нативный плагин для Claude Code. По сути, это слой «инженерного здравого смысла» между моделью и базой данных. ИИ остаётся умным, но перестаёт быть опасным для продакшена. Вот это и есть настоящее «прокачивание ассистентов». https://github.com/timescale/pg-aiguide @sqlhub

Горизонтальное масштабирование PostgreSQL — проблема, которая неизбежно возникает при работе с большими данными и высокими нагрузками. Когда количество транзакций растёт до миллионов, стандартных возможностей PostgreSQL уже недостаточно: сопровождение усложняется, риски увеличиваются, а вывод новых продуктов замедляется. Yandex B2B Tech представили Managed SPQR — управляемый сервис горизонтального масштабирования PostgreSQL на платформе Yandex Cloud. Решение позволяет распределять данные между шардами, автоматически балансировать нагрузку и снимать с команд значительную часть операционных задач. Managed SPQR помогает: 🔴 ускорить разработку и запуск продуктов в 3–4 раза; 🔴 снизить операционные риски и нагрузку на инфраструктуру; 🔴 сэкономить до 15 млн рублей при запуске высоконагруженных сервисов. Технология уже используется в проектах Яндекса и у внешних компаний, включая финтех и e-commerce. 📅 5 февраля в 12:00 команда Yandex B2B Tech проведёт вебинар, посвящённый запуску public preview сервиса. Участникам расскажут об архитектуре Managed SPQR, автоматической перебалансировке данных, мониторинге и реальных кейсах, а также разберут выбор ключа шардирования. 🔗 Регистрация и подробности — по ссылке.

✅ ШПАРГАЛКА: Как правильно поднимать БД перед проектом Главная ошибка новичков - “у всех база разная”. В итоге миграции ломаются, схема плывёт, на CI одно, у тебя другое, в проде третье. Правильный старт всегда одинаковый: 1) Поднимай БД через Docker - чтобы у всей команды окружение было идентичным 2) Все параметры (пароль, порт, имя БД) храни в .env 3) Схему меняй ТОЛЬКО через миграции (Flyway/Liquibase/EF/Alembic) 4) Добавь healthcheck - сервис не должен стартовать раньше БД 5) Сделай команды backup/restore - пригодится в любой момент Так ты гарантируешь: - у всех одна и та же база - быстрый старт проекта за 3 минуты - деплой без сюрпризов

1) Создай .env
cat > .env << 'EOF'
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=app123
POSTGRES_PORT=5432
EOF

2) docker-compose.yml для Postgres + healthcheck
cat > docker-compose.yml << 'EOF'
services:
  postgres:
    image: postgres:16
    container_name: app-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  pgdata:
EOF

3) Запуск
docker compose up -d

4) Проверка
docker compose ps

5) Backup
docker exec -t app-postgres pg_dump -U app app > backup.sql

6) Restore
cat backup.sql | docker exec -i app-postgres psql -U app -d app

Отменяем все мемы про дроп базы