SQLite *

Полторы недели назад я выложил на Habr бота с лентой хороших новостей на sqlite-vec за $5/мес. Потом пришли живые юзеры — и началось самое интересное. Не код. Эксплуатация.

За 10 дней в проде:

🪦 Бот дважды умирал незаметно — поллил Telegram и казался живым, но не создавал ни одной новости по 4–5 дней. Один раз — OOM на загрузке модели, другой — feedparser.parse(url) без таймаута заморозил весь пайплайн.

📉 Метрика релевантности «рухнула» до 30% — и я чуть не откатил рабочую фичу. Оказалось, один юзер поставил 106 дизлайков из 228 и отравил и метрику, и приор источников. Починил, считая по уникальным юзерам — правда оказалась 42%.

🎯 Реакции 78 человек сами показали, какие источники выкинуть: tech-аудитория отвергает общие новости и любит курируемое.

Внутри — реальные логи, код фиксов (httpx-таймаут, watchdog, робастные метрики) и уроки про надёжность воркеров и доверие к цифрам.

👉 @futur_e_news_bot

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.

Codex хорош, пока не приходится в пятый раз объяснять ему одни и те же правила проекта: где проверки прав, как запускать тесты, почему не надо тащить старые alias-модули и что мы уже решали в прошлом чате.

Поэтому я сделал Hermes Codex Plugin — плагин, который хранит правила, summaries и прошлые решения в SQLite, ищет их через FTS5 и подкладывает Codex только маленький релевантный кусок контекста.

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).

Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.

Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

Хотел ленту новостей без двух вещей: дублей (одно событие из пяти каналов с разными заголовками) и потока негатива по утрам.

Получился Telegram-бот, который по умолчанию показывает только хорошие и нейтральные новости — а тяжёлый контент включается в настройках на 4 уровнях. Плюс он убирает дубли, переводит RU↔EN и подстраивает выдачу под твои реакции 🔥 ❤️ 😢.

Но самое интересное — он живёт на одной машине Fly.io за ~$5 в месяц. В статье разбираю, как:

заменил Postgres + pgvector на встраиваемый sqlite-vec и убрал отдельную БД-машину;

гоняю типизацию, перевод и оценку тональности через бесплатные LLM на OpenRouter (счёт $0–1/мес);

считаю эмбеддинги локально на fastembed/ONNX без внешних API;

собрал рекомендательное ядро на «векторе вкуса» с EWMA и анти-баблом.

И, конечно, грабли: sqlite-vec, который ломался на arm64; vec0 без INSERT OR REPLACE; fastembed, сменивший пулинг между версиями; и LLM, которая «подкручивала» оценки негатива, пока я не дал ей чёткую рубрику.

👉 Бот живой, можно потрогать: @futur_e_news_bot

Мне нравится чистый SQL.

Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.

Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»

В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.

Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.

Мне пришла задача на исследование — выбрать хранилище для промышленной телеметрии. Я раньше с таким вообще не работал. Ни с временными рядами, ни с реактивным программированием, ни с WebSocket. Работал только с Postgres.

Слышал про Redis, но не применял. На выбор — SQLite или Redis, надо исследовать что лучше. Пошёл читать. Нашёл TimescaleDB и ещё кучу вариантов — у каждого свои плюсы.

Основной плюс SQLite — там можно писать запросы, SQL знакомый, Spring интеграция есть. Скорость записи меня вообще удивила — и у Redis, и у SQLite. Я не ожидал таких цифр.

Долго не мог понять зачем вообще Redis, если там нет нормального поиска. Просто хэши ключ-значение. Хочешь найти все датчики по типу объекта — не работает. Я такой: ладно, Redis минус, берём SQLite.

Сделал прототипы. Потестировал один поток — SQLite летит, 370 000 вставок в секунду. Redis ещё быстрее — 650 000. Нашёл RediSearch с поиском по индексам — оч круто, но скорость падает до 150 000. SQLite снова выглядит выигрышнее.

И вот я запускаю 100 потоков на SQLite.

В логах появляется:

Это восьмая статья из моей серии про инженерные решения в ONEMIX. До этого было про клиентскую часть мессенджера: кэш сообщений, E2E, WebRTC звонки, Electron, outbox‑паттерн. Параллельно про AI‑агента Лиру и мнение про вайб‑кодинг.

Сегодня про серверную сторону. Backend ONEMIX — это один файл main.py на 19 603 строки, 379 эндпоинтов, FastAPI + SQLite, держит мессенджер с регистрацией через SMS, звонками через LiveKit, E2E через Double Ratchet, push‑нотификациями на iOS и Android. Этот файл я пишу больше года. За это время он эволюционировал из прототипа на 800 строк в production монолит.

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

Сразу важная оговорка. У меня не было требования держать 100к одновременных пользователей или 10к RPS. Это бэкенд под мобильное приложение с трафиком который для соло‑разработчика разумно поддерживать одному. Если у вас задачи другого масштаба, мой опыт может не подойти.

Я устал разбирать длинные видео, голосовые и кружки в Telegram вручную. Сначала это было терпимо, потом каналов стало больше двадцати — и контент просто перестал помещаться в день.

Так появился Sumify: бот, который сам достает главное из медиа и превращает его в выжимку, конспект и ответы на вопросы.

Если серьезно, то сегодня мы поговорим про БАЗЫ данных. Как-то один мой друг разработчик сказал, что программирование можно понимать как

Если вы ведете несколько проектов одновременно, вы знаете проблему управления информацией. Мысль пришла в голову — записал куда-то. Через месяц пытаешься вспомнить: где это было? Сохранил в папке где-то на компьютере? В заметках телефона? В рабочем чате или личных сообщениях?

Если не нашел — идея ушла. Или осталась, но найти её — отдельный квест и потеря времени, которое хотелось бы потратить с пользой, а не на поиски.

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

Изначально я пытался найти для себя идеальный инструмент. Notion, Obsidian, Evernote — ни один не решал мою задачу в комплексе: быстро сохранить мысль, не потерять её, а потом легко найти и связать с другими.

Поэтому я написал свою систему.

Статья — не «продажа курса» и не «уникальный продукт». Это описание того, как я решал свои задачи, какие решения принимал и что из этого вышло. Если вы тоже теряете время при поиске нужной информации — возможно, найдёте здесь что-то полезное.

Pusk — self-hosted сервер алертов на 16 МБ. Один бинарник, без внешних сервисов, частично совместим с Telegram Bot API (13 методов из 80+).

Типичная ситуация: несколько серверов, Zabbix собирает метрики, Python‑боты шлют алерты в Telegram. У кого‑то это веб‑проект, у кого‑то видеонаблюдение, у кого‑то живые эфиры, где 2 минут без алерта = зрители видят чёрный экран. Работало годами.

А потом канал до API отвалился. Причина неважна — лимиты, блокировки, авария на стороне провайдера. Алерты встали. Нужен был свой канал доставки, который не зависит от внешних сервисов.

Привет, Хабр! С выходом платформы MAX у разработчиков появилось новое игровое поле. Пока комьюнити спорит о шансах на победу в гонке мессенджеров, маркетологи уже начали переливать туда трафик.

Самая типовая задача для бизнеса сейчас — бот обратной связи. В Telegram эту нишу давно занял Olgram, а вот в Max — чистый лист. Давайте вместе напишем свой аналог. Это отличный кейс, чтобы разобраться с новым API, не углубляясь в лишнюю инфраструктуру.

Стек: Почему все оказалось проще, чем кажется

Для MVP (Minimum Viable Product) мы будем использовать Node.js и официальную библиотеку @maxhub/max-bot-api.

Привет Хабр! В прошлой статье мы детально разобрали функциональные зависимости. Возможно, после нее у вас, как и у многих, остался закономерный вопрос: зачем нам вообще так париться, выискивая эти зависимости? Как это применяется в проектировании баз данных?

Естественно, можно спроектировать базу данных, вообще не заботясь ни о каких правилах. И она даже будет работать! Все будет прекрасно ровно до первого ее реального использования в продакшене. При проектировании «абы-как» возникают три типовые проблемы: избыточность, аномалии обновления, аномалии удаления.

И вот это уже плохо.

У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:

• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя

В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.

SQL в 2026: что реально нужно знать аналитику? 🤔
Спойлер: не только JOIN и GROUP BY, а еще и оконные функции, когортный анализ, оптимизация запросов и работа с BigQuery.
Пошаговый план для новичков с бесплатными тренажерами, курсами (да, Карпов там есть) и списком тем, без которых вас не наймут.

Давайте разберем четкий план: что учить, где брать практику и как не потеряться в море информации 👇

Переезд с macOS на Windows для разработчика часто сопровождается болью от потери привычного инструментария. В моем случае решающим стимулом свитчнуться на ПК стала мощная видеокарта. Сейчас мой верный MacBook всё так же лежит на столе и даже подключен к мониторам, но по факту именно Windows (как бы сильно она мне ни не нравилась) стала основной рабочей системой.

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

Штатный инструмент Windows (Win+V) разочаровал моментально: лимит в 25 элементов, отсутствие поиска и полное обнуление после перезагрузки ОС. Поиск альтернатив тоже не увенчался успехом: Ditto надежен, но выглядит как гость из 2005 года, а мощный CopyQ имеет перегруженный интерфейс суровой системной утилиты. Ни в одном из них не было современных функций вроде OCR «из коробки» или базовой интеграции с LLM для обработки текста на лету.

Решение напрашивалось само собой — написать свой велосипед. Но сделать его легким, быстрым и без Electron. В этой статье расскажу о том, как устроен Beetroot — менеджер буфера обмена с бесконечной историей, нативным OCR и AI-трансформациями.

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

В ритейле каждый сантиметр полки – это деньги (буквально). В этой статье я разберу примеры задач, которые решает аналитик в ритейле, и покажу, как их решать на SQL.
Каждая задача сложнее предыдущей для каждой есть код и готовые синтетические данные, поэтому все результаты можно получить самостоятельно, повторив код.

Один разработчик, один AI-напарник (Claude), ноль инвесторов. Рассказываю, как за 4 месяца я построил платформу автоматизации контент-маркетинга с 14 микросервисами, собственной очередью задач на SQLite вместо Redis, мультимодельным AI (MiniMax, YandexGPT, Replicate) и circuit breaker для автоматического fallback между провайдерами. Всё на одном сервере, всё через npm install.