IYKYK 😆

@ohmydataengineer

https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks

Прекрасная статья о том, что момент, когда вам в большинстве случаев, перестанет хватать Posgres на самом деле очень и очень далек.
И как Pub/Sub решение, и как Redis решение, и Data Lake решение.

Циферки, метрики, замеры внутри, все как вы любите 😃


P.S. Конечно же, никто не говорит о том, что Kafka надо заменять на Postgres. The claim isn’t that Postgres is functionally equivalent to any of these specialized systems. The claim is that it handles 80%+ of their use cases with 20% of the development effort.

Но поздно, стервятники уже налетели...https://www.morling.dev/blog/you-dont-need-kafka-just-use-postgres-considered-harmful/

@ohmydataengineer

https://github.com/toon-format/toon

Если у вас есть какие-либо автоматизации с использованием LLM и вы в них кидаетесь данными, то вот тут ребята собрали небольшой оптимизатор структур, позволяющий экономить на токенах.

@ohmydataengineer

Российские ETL решения....

Я даж не знаю, смеяться или плакать..🙈

Специально оставлю вам ссылку с картинки https://russianbi.ru/ - чтобы вы сами посмотрели на это.

https://bfcm.shopify.com

У Shopify в этом году на Βlack Friday было 45kk сообщений в Кафку в секунду...

(скриншот, конечно, сегодняшний, а не пятничный, но сам вебсайт оч классный с техническими метриками)

А сколько там пасхалок на этом сайте... 😃 (одна из них что он жрет гигабайт оперативки)

@ohmydataengineer

MiniO все.

This project is currently under maintenance and is not accepting new changes.
• The codebase is in a maintenance-only state
• No new features, enhancements, or pull requests will be accepted
• Critical security fixes may be evaluated on a case-by-case basis
• Existing issues and pull requests will not be actively reviewed
• Community support continues on a best-effort basis through Slack


https://github.com/minio/minio

@ohmydataengineer

Показываем аудитории молодые open-source проекты. Мне не жалко, вдруг кому-то будет интересно.


🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных

🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);

Запуск через Docker:
docker run -d
--name postgresus
-p 4005:4005
-v ./postgresus-data:/postgresus-data
--restart unless-stopped
rostislavdugin/postgresus:latest

📌 GitHub

Новые поглощения и покупки: IBM покупает Confluent (не путать с Confluence 😆, это которые Kafka)

https://www.reuters.com/technology/ibm-nears-roughly-11-billion-deal-confluent-wsj-reports-2025-12-08/


@ohmydataengineer

https://karpathy.bearblog.dev/year-in-review-2025

Andrej Karpathy (ну тот, который был главнюком за AI в Tesla и не только) подвел отличные и оч лаконичные итоги года.
Еще мне на прошлой неделе удалось посмотреть два интересных интервью и один докладик

- Andrej Karpathy — “We’re summoning ghosts, not building animals” - https://www.youtube.com/watch?v=lXUZvyajciY

- Ilya Sutskever – "We're moving from the age of scaling to the age of research"- https://www.youtube.com/watch?v=aR20FWCCjAs

- Andrej Karpathy: Software Is Changing (Again) - https://www.youtube.com/watch?v=LCEmiRjPEtQ


И нет, это не х2 скорость, это он так в реальности говорит 😃


@ohmydataengineer - канал "Труба данных" про всякое в мире работы с данным

Хотя про AI-агентов сейчас пишут буквально из каждого утюга, в этой статье мне особенно зацепился один момент — визуализация зависимости качества ответов LLM от длины контекста. Интуитивно мы все чувствуем, что «чем больше — тем лучше», но на практике кривая выглядит иначе: после определённого порога контекст начинает не помогать, а мешать. Сигнал тонет в шуме, модель теряет фокус, а качество решений деградирует. Забрал эту картинку себе в копилку как хорошее напоминание.

Из этого логично вытекает важный тезис: формулировка задачи вторична, первична политика контекста. Не «как красиво спросить», а что именно и в каком объёме сейчас действительно нужно модели. Принцип «минимум, достаточный для текущего шага» оказывается куда более надёжным, чем попытка загрузить в контекст всё возможное «на всякий случай».

Отдельно понравилась мысль про инструменты. Да, туллинг расширяет возможности LLM, но каждый их вывод — это ещё один удар по контекстному бюджету. Если инструменты шумят, возвращают избыточные данные или нестабильный формат, агент быстро начинает деградировать. Поэтому критичны строгие контракты, малый, предсказуемый и структурированный вывод — иначе инструменты становятся источником энтропии, а не силы.

История сообщений — ещё одна зона инженерной ответственности. Хранить всё подряд — плохая стратегия. Актуальное должно быть доступно, «закрытые» куски — сжаты и зафиксированы в виде состояния, всё остальное — безжалостно отброшено. Контекст — не лог событий, а рабочая память, и к ней применимы те же принципы, что и к архитектуре систем.

Итог для меня простой: контекст-инжиниринг — это полноценная дисциплина проектирования. Каждая загрузка в окно контекста — осознанное решение с ограничениями. Надёжность агента обеспечивается не магией промпта, а управлением информационным бюджетом, продуманной retrieval-стратегией и регулярной компакцией состояния. Именно здесь сейчас проходит граница между «демо» и реально работающими агентными системами.

https://newsletter.systemdesign.one/p/what-is-context-engineering

https://www.youtube.com/watch?v=rmvDxxNubIg

В личку принесли еще один прекрасный, небольшой доклад про Context Engineering.
Из забавного - почти ко всем советам, про которые говорится в докладе, дошел и стал применять самостоятельно, видимо я не настолько туп 😁

@ohmydataengineer - канал "Труба данных" про всякое в мире работы с данным