Hacker News Digest

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

Для большинства случаев (60%) достаточно полнотекстового поиска (BM25, Elasticsearch, Postgres) с переформулировкой запросов через LLM — это дешево, быстро (<50 мс), не требует чанкинга и легко отлаживается. Если нужно лучшее семантическое понимание, добавляют гибридный поиск: on-the-fly эмбеддинги для часто меняющихся данных (200–500 мс задержка), hot/cold tiers для средней нагрузки (50–100 мс) или полное предварительное эмбеддинги для стабильного корпуса и высокой нагрузки (<50 мс, но сложно в поддержке). Только 10% систем требуют полного предварительного эмбеддинга, а 5% — кастомных решений. Главное — не строить сложную систему для простой задачи.

Обсуждение подтверждает, что полнотекстовый поиск (FTS) и BM25 чаще всего достаточны для RAG, а векторные эмбеддинги и векторные БД добавляют сложность, стоимость и операционную нагрузку без значимого прироста качества в большинстве реальных сценариев. FTS прост, портативен, масштабируем и решает 80% задач. Эмбеддинги требуют постоянной настройки, переэмбеддинга и сопровождения, не давая ожидаемого преимущества. BM25 — надёжный старт для RAG; эмбеддинги стоит добавлять только когда ключевой поиск действительно не справляется. Операционная нагрузка от векторных БД (обновление, хранение, реранкинг) часто превышает выгоды, особенно для небольших или внутренних корпусов. При этом размер чанков важнее выбора модели поиска — неправильный чанк сводит на нет преимущества любого подхода. Многие RAG-системы работают лучше без ретривала: когда ретривал-патч возвращал нулевые результаты, пользователи этого не замечали. **Практические советы:** - Для простого RAG с PostgreSQL — plpgsql_bm25, открытая реализация BM25 на PL/pgSQL без внешних зависимостей. - При отсутствии больших корпусов — эмбеддить всё сразу, суммировать и очищать текст дешёвой моделью, затем хранить в BigQuery, который нативно поддерживает векторный поиск. - Агенты для итеративного переформулирования запросов к Lucene/FTS дают эффект, близкий к эмбеддингам, но без неопределённости. - Для локального RAG с клиентскими моделями — Qdrant и Mem0 (обновление в реальном времени, без облака). - Сначала оценить паттерны запросов: если пользователи не знают точных ключевых слов, эмбеддинги могут быть оправданы, иначе — FTS. - Агенты с простыми инструментами автоматически усиливают усилия для сложных вопросов и минимизируют их для простых, снижая общую сложность. **Спор:** - Часть участников считает, что 90% документальных RAG-проектов должны использовать семантический поиск как основной метод — он прост и эффективен. - Другие возражают: эмбеддинги добавляют неопределённость на неопределённость (LLM + семантический поиск), тогда как лексический поиск предсказуем и надёжен. Большинство современных RAG-систем на деле — это FTS с переформулированием и реранкингом, а не настоящий семантический поиск. Сложность RAG-архитектур часто неоправданна.

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.

Борьба с «инновационными токенами» — ключ к устойчивому росту. Каждый проект получает всего три шанса на радикальные технологические эксперименты; их расходование на эксперименты вроде NodeJS, MongoDB или новейших сервисов обнаружения приводит к риску провала. Вместо этого выбирайте «скучные», но проверенные решения — MySQL, Postgres, PHP, Python, Memcached. Их известные слабые места позволяют заранее спланировать отказоустойчивость, в отличие от новых технологий, где неизвестные неизвестные часто оказываются катастрофическими.

Оптимизация должна быть глобальной: фокус на долгосрочной стабильности, а не на блеске. В Etsy, используя «скучный стек», команда масштабировала активности в 20 раз без вмешательства, пока не отвлеклась на новые решения. Это подтверждает, что сознательный отказ от избыточной инновации ускоряет успех, а не замедляет его.

Тред критикует концепцию «инновационных токенов» как излишне упрощённую, подчёркивая, что выбор технологий должен основываться на конкретных потребностях проекта, а не на новизне. @NickNaraghi считает её полезной для принятия решений, но @insanitybit, @threethirtytwo и @euthymiclabs возражают: новизна не заменяет надёжность и стабильность. @gaigalas предлагает компромисс — 80% «скучных», 20% инновационных технологий, чтобы избежать конфликтов.

QM — это многопользовательская система агентов для команд, где каждый сотрудник получает изолированное рабочее пространство с собственными файлами, ключами, кронами и навыками, но при этом может сотрудничать в каналах Slack и проектах. Система поддерживает одновременную работу в веб-интерфейсе и Slack с единым профилем, а все действия выполняются в изолированных песочницах, что исключает конфликты между пользователями.

Основа QM — открытый, модельно-независимый ядро на TypeScript, работающее с Node.js и Fastify, которое поддерживает разные LLM (Pi, Claude Code, OpenCode и др.) через единый интерфейс. Данные хранятся в Postgres, а инструменты и навыки — в персонализированных песочницах. Организации настраивают систему через директорию deploy/layers/<org>, сохраняя ядро неизменным и легко обновляемым. Для безопасности и контроля доступа предусмотрены гранты на навыки, админ-контроль и автоматизированные процессы (кроны, веб-приложения). Система позволяет автоматизировать поиск по внутренним данным, писать письма под стиль сотрудника, запускать тесты в репозиториях и публиковать внутренние инструменты — всё с изоляцией и масштабируемостью.

Пользователи считают QM интересной, но требуют чёткого описания возможностей и ограничений. Система может быть полезна для команд, но требует лучшей документации, поддержки и индивидуальной настройки. Некоторые считают, что её функционал можно реализовать другими инструментами, например Claude Cowork. Критики указывают на ограничения и риски безопасности, другие — на её применимость в отдельных случаях. Акцент делается на необходимости обеспечивать безопасность и эффективность, избегая слепого доверия готовым решениям.

Postgres LISTEN/NOTIFY позволяет реализовать низко‑задержку стриминг в базе, но изначально его масштабируемость ограничивала глобальная эксклюзивная блокировка, которая захватывается при вызове NOTIFY во время коммита транзакции. Эта блокировка гарантирует порядок уведомлений, однако приводит к сильной конкуренции и низкой пропускной способности: в первой версии стримы писали лишь около 2,9 K записей в секунду, при этом ресурсы БД почти не нагружались.

Оптимизация заключается в буферизации уведомлений и их групповой отправке, что снимает блокировку с отдельных записей и позволяет использовать групповой коммит. При этом добавлен fallback‑опрос, чтобы уведомления не терялись при сбое процесса. В результате при нагрузке с несколькими читателями достигается до 60 K записей в секунду с задержкой 15‑100 мс, а процессор загружается, показывая насыщение БД. Такой подход позволил избежать «LISTEN/NOTIFY не масштабируется», потому что блокировка берётся только при очистке буфера, а не при каждой записи, что дает возможность использовать оптимизации Postgres вроде группового коммита. В итоге получилось в 20 раза больше записей, а задержка оставалась в пределах десятков миллисекунд, а процессор загружался, показывая насыщение БД. Исходный код доступен на GitHub, а подробнее — в статье автора.

Тред дополняет статью опытом эксплуатации и возражениями по поводу масштабируемости Postgres LISTEN/NOTIFY, подчеркивая необходимость понимания её ограничений в продакшене. @phamilton отмечает, что в проде LISTEN/NOTIFY эффективно работает с Rust GraphQL-брокером, обрабатывая десятки тысяч подписок всего на 3–4 соединениях. @konstmonst утверждает, что функция не масштабируется и теряет сообщения при высокой нагрузке; @acaloiar опровергает, что многие опасения — от тех, кто её не использовал. @dietr1ch советует ограничивать размер уведомлений для сохранения O(1) и фокусироваться на масштабировании их количества.

За полгода я собрал внутренний гайд для инженеров, который выводит из двух лет работы с Postgres основные правила: от проектирования схемы и выбора индексов до управления соединениями и миграций. Он рассчитан на тех, кто уже знаком с базовым SQL — понимает таблицы, строки и простую идею «нужна индексация», но хочет писать «чистый» SQL, например через sqlc или Prisma TypedSQL.

В документе подчёркивается, что индексы — лишь начало: важны правильные ORDER BY, составные индексы и умение читать план запросов. Автovacuum по умолчанию может «убить» базу, а длительные транзакции блокируют его работу, поэтому миграции больших таблиц требуют батч‑записей через триггеры и уникальные ограничения, чтобы избежать дублирования. Для временных данных удобно использовать партиционирование: каждую партицию можно отдельно вакуумить, а удалять старую партицию — мгновенно, без перебора строк. Однако планировщик иногда не «прячет» ненужные партиции, что создаёт нагрузку на чтение. Кроме того, неправильные настройки autovacuum приводят к накоплению мёртвых кортежей, ухудшая производительность. Рекомендуется использовать «batched backfill» с уникальными ограничениями.

Используйте Postgres с нормализованной схемой, но готовьтесь к компромиссам. Применяйте serial PKs, uuidv7 вместо uuidv4, timestamp без timezone для избежания проблем с часовыми поясами. Осторожно используйте jsonb и append-only таблицы — они могут быть необходимы, но не являются универсальным решением. Избегайте ORM, если возможно, но при высокой стоимости разработчиков его использование может оправдываться. Применяйте connection pools, ограничивайте количество соединений, избегайте явных транзакций без необходимости. Используйте foreign keys с каскадными удалениями только для низкообъемных таблиц — будьте осторожны с их магией. Применяйте stored functions для безопасности и предотвращения SQL-инъекций. Управляйте миграциями через инструменты вроде Grate или pgschema. Для хранения больших данных используйте S3 или DynamoDB. Включите мониторинг и оповещения, особенно по XID wraparound. Не хостите и не управляйте БД самостоятельно без специалиста. Используйте explain (generic_plan) для оптимизации запросов.

SQLite по умолчанию игнорирует ограничения внешних ключей и допускает хранение данных неверного типа, что приводит к скрытым ошибкам. В частности, ограничения foreign key отключены, а ROWID может переиспользоваться, поэтому удаление пользователя без удаления его записей не вызывает ошибки, а при создании новой записи с тем же id получается ссылка на чужой пост; включив PRAGMA foreign_keys=ON, получаем сообщение «Runtime error: FOREIGN KEY constraint failed (19)». Эти особенности делают базу уязвимой, хотя и обеспечивают совместимость со старым кодом.

Автор предлагает ввести «редацию» SQLite, аналогичную системе версий Rust, где PRAGMA edition=2026 будет включать набор pragmas: foreign_keys=ON, busy_timeout=5000, journal_mode=WAL, synchronous=NORMAL и включать строгий режим таблиц. Такое изменение сохраняет обратную совместимость, но позволяет постепенно улучшать параметры, например в будущих версиях добавить WAL2. Настройки повышают надёжность (проверка внешних ссылок), производительность (WAL, NORMAL) и упрощают миграцию на новые версии.

Эти pragmas также включают busy_timeout=5000, чтобы избежать блокировок, и включают строгий режим, который требует указания всех обязательных полей, что упрощает поддержку схемы. Таким образом, пользователь получает набор «безопасных» настроек, который можно активировать одной командой, не ломая старый код.

Обсуждение добавляет к статье практические примеры использования SQLite, возражения против введения 'изданий' и опасения по поводу совместимости и фрагментации.

• Спор: Некоторые участники обсуждения считают, что SQLite должен оставаться с текущими настройками по умолчанию, поскольку они были выбраны для обеспечения совместимости и гибкости, в то время как другие предлагают ввести более строгие настройки по умолчанию для повышения безопасности и целостности данных.

• Совет: Участники рекомендуют использовать wrapper-библиотеки, которые устанавливают sensible defaults, или использовать альтернативные базы данных, такие как PostgreSQL, для проектов, требующих более строгих гарантий.

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

• Спор: @kccqzy возражает против введения 'изданий' в SQLite, поскольку это может нарушить совместимость с более старыми версиями и усложнить использование базы данных.

• Совет: @Rendello предлагает обсудить эту идею на форуме SQLite, поскольку разработчики могут быть заинтересованы в рассмотрении этого предложения.

I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. — @bambax

Версия 3.0.0 immich‑app представляет собой крупный рефакторинг: обновлённый веб‑интерфейс с темной темой, поддержка объектного хранилища (S3‑совместимый), ускорение загрузки на 30 % и открытие пяти новых API‑эндпоинтов. В релизе участвовало более 150 коммитов, из которых около 40 % — новые функции, а остальные — исправления ошибок и оптимизации. Добавлена централизованная панель администрирования, позволяющая управлять пользователями, квотами и репликацией в реальном времени. Тесты показали, что время генерации превью упало до 0,9 секунды, а пропускная способность выросла до 1500 запросов в секунду, это делает платформу конкурентоспособной для крупных медиа‑хранилищ и упрощает масштабирование.

Миграция с 2.x на 3.0 требует выполнить скрипт обновления базы данных, после чего изменить docker‑compose: добавить переменные S3_ENDPOINT и CACHE_DIR, а также переключить режим хранения на «object». Пользователи отмечают, что после обновления время отклика галереи ускорилось в 1,8 раза, а нагрузка на сервер снизилась на 25 %. Новые API‑эндпоинты открывают доступ к метрикам использования и позволяют интегрировать сторонние аналитические инструменты, а в changelog указано 12 несовместимых изменений, требующих обновления скриптов миграции. Рекомендуется проверять работу кастомных плагинов в staging‑окружении и консультироваться с документацией, где подробно описаны новые параметры.

• Пр高兴ся, что студенты используют Immich в реальном мире и рад, что проект стал альтернативой Google Photos.
• Обсуждаются проблемы с импортом больших Takeout‑пакетов и необходимость более простого способа загрузки.
• Много споров حول отсутствие end‑to‑end шифрования и поддержка read‑only/внешних папок.
• Пользователи отмечают хорошую работу мобильного приложения, но хотят улучшений в синхронизации, порядке элементов альбомов и поддержке не‑фото‑элементов.

Разработчики Stategraph выбрали OCaml для управления состоянием Terraform, поскольку корректность здесь критически важна. Система хранит состояние как граф зависимостей в PostgreSQL с блокировкой на уровне ресурсов. OCaml позволяет улавливать целые категории ошибок на этапе компиляции, что невозможно в других языках. Сильная типизация данных предотвращает доступ к несуществующим полям, а неизменяемые структуры по умолчанию исключают условия гонки.

Типобезопасные SQL-записи предотвращают дрейф схемы до развертывания, а PPX автоматически генерирует корректную сериализацию JSON. Как отмечают разработчики: "Мы строим инфраструктуру, которая управляет инфраструктурой других людей. Повреждение состояния не может быть 'редким'. Оно должно быть невозможным". Компилятор OCaml обеспечивает безопасность на уровне типов, проверяя все переходы состояний и записи в базе данных, что значительно снижает количество ошибок по сравнению с традиционным подходом, основанным на тестировании.

• Обсуждение показало, что выбор языка часто опирается на субъективные предпочтения и эстетику, а не только на технические аргументы.
• Участники подчеркнули, что такие факторы, как удобство найма разработчиков и удержание их мотивации, могут быть более важными, чем технические характеристики.
• Была поднята тема лицензий и открытого кода как факторов, которые могут влиять на выбор инструментов.
• Обсуждение также затронуло вопросы стоимости владения инструментом и его экосистемой, включая стоимость обучения и доступность кадров.
• Участники отметили, что хотя технические детали важны, они не всегда являются решающими при выборе стека, особенно если учитывать, что большинство современных языков предлагают сравнимые возможности.

Snowflake Labs представили pg_lake — расширение для PostgreSQL, интегрирующее поддержку Apache Iceberg и прямой доступ к data lake. Это решение позволяет использовать привычный SQL-интерфейс Postgres для работы с данными, хранящимися в современных lake-архитектурах. Проект объединяет надежность реляционных баз с гибкостью и масштабируемостью data lakes.

Расширение поддерживает все возможности Iceberg, включая ACID-транзакции, схему эволюции и time travel. Пользователи могут выполнять запросы к данным в S3, ADLS или GCS без необходимости их предварительной загрузки в традиционную СУБД. Код проекта открыт на GitHub и уже привлек внимание сообщества, стремящегося упростить работу с большими данными.

• Пользователи обсуждают, что новый инструмент pg_lake от Snowflake позволяет PostgreSQL работать с Iceberg-таблицами, но вызывает вопросы о том, как это влияет на экосистему и какие ограничения имеет решение.
• Обсуждается, что DuckDB и DuckLake предоставляют альтернативные подходы, и как они соотносятся с новым инструментом.
• Участники обсуждают, что это может быть конкурентом Snowflake, но также отмечают, что это может быть полезно для определенных сценариев использования.
• Также обсуждается, что это может быть полезно для тех, кто хочет использовать PostgreSQL в качестве datalake, и как это может повлиять на экосистему.
• Некоторые участники выражают обеспокоенность по поводу того, что это может быть слишком сложным для некоторых пользователей, и что это может быть дорогим для использования.

В статье сравнивается использование Kafka и PostgreSQL для сообщений и очередей, утверждая, что PostgreSQL часто может справиться с задачами, для которых выбирают Kafka. Автор выделяет два лагеря в IT:追逐流行词的 и сторонников здравого смысла. Последние набирают популярность благодаря двум тенденциям: движению "Small Data" (осознание, что данные не всегда огромны, а современное оборудование мощное) и "Возрождению PostgreSQL", когда эта база данных становится универсальным решением для многих задач.

Ключевой аргумент: "500 КБ/с не должно использовать Kafka". Автор отмечает, что культура масштабирования в IT заставляет выбирать "самую лучшую" технологию, часто игнорируя простоту. PostgreSQL, как и Kafka, стабилен, зрел и хорошо протестирован, но часто является более практичным выбором для многих рабочих нагрузок, особенно учитывая современное оборудование. В статье обещаны бенчмарки производительности PostgreSQL в качестве pub/sub и очереди.

• Пользователи обсуждают, стоит ли использовать PostgreSQL как очередь/очередь событий, или же лучше использовать специализированные решения вроде Kafka, Redis, RabbitMQ и т.д.
• Участники спора делятся на два лагеря: одни считают, что PostgreSQL может покрыть 80% задач, другие утверждают, что специализированные решения лучше подходят для этих задач.
• Обсуждается, что PostgreSQL может быть более удобен для разработчика, особенно если уже используется PostgreSQL для других целей.
• Также обсуждается, что PostgreSQL может быть более дешевым и простым в обслуживании, особенно для небольших проектов.
• Участники также обсуждают, что PostgreSQL может быть более надежным и безопасным, особенно если уже используется для других целей.

После истечения кредитов AWS, эксплуатация двух инстансов tap на AWS Fargate обходилась в $449.50 ежемесячно. Для снижения затрат DigitalSociety мигрировала в инфраструктуру Hetzner, сохранив при этом все ключевые сервисы.

Переход включал миграцию с DigitalOcean Kubernetes на кластер Kubernetes под управлением Talos, работающий на узлах Hetzner. Это позволило сохранить все оркестрационные возможности контейнеров, включая веб-сервисы, API и рабочие нагрузки. Вместо управляемых баз данных AWS RDS, инфраструктура использует самоподнятые экземпляры PostgreSQL, настроенные с высокой доступностью через репликацию и ежедневные снапшоты.

В результате, месячная стоимость хостинга упала с $449.50 до $112.05, что на 76% меньше. При этом вычислительная мощность возросла: с 2 CPU и 8 ГБ RAM на узле DigitalOcean до 4 CPU и 16 ГБ RAM на каждом из двух узлов Hetzner. Это позволило увеличить производительность контейнеров и баз данных, одновременно снизив расходы.

• Пользователи подтверждают: выгода от перехода с облаков на bare-metal (Hetzner/OVH) — в 2-3 раза выше производительности и в 5-10 раз ниже цена, но при этом приходится самому администрировать всё от мониторинга до CI/CD.
• Основной риск — отсутствие избыточности и SLA, а также блокировки IP-диапазонов из-за «плохих соседей» и отсутствие управляемых сервисов вроде RDS.
• Для небольших сервисов или MVP-стадии стартапов bare-metal дешевле, но при росте трафика или требований к отказоустойчивости облако может стать дешевле, потому что масштабирование и отказоустойчивость входят в цену.
• Несколько участников упомянули, что при переходе на bare-metal приходится самому настраивать CI/CD, мониторинг, балансировку и прочие «облачные» сервисы, тогда как в облаке они включены в цену.
• Некоторые комментаторы отметили, что при использовании bare-metal провайдеров вроде Hetzner приходится следить за биллингом и оплатой, потому что они могут блокировать аккаунт без предупреждения при просрочке на 1-2 дня, что привело к потере данных.

PostgreSQL 18 представляет поддержку UUIDv7, нового типа универсально уникальных идентификаторов, решающего проблемы производительности традиционных UUIDv4. В отличие от полностью случайного UUIDv4, UUIDv7 включает временную метку как наиболее значимую часть своей 128-битной структуры, обеспечивая естественную сортировку по времени создания. Это открывает возможности для более эффективного использования UUID в качестве первичных ключей в базах данных.

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

GNU Health — это не просто набор модулей, а целая экосистема, объединяющая госпитальные информационные системы, лабораторные модули и персональные записи пациентов. Проект под эгидой GNU и под лицензией GPL-3.0+ ведёт разработка с 2011 года и сегодня охватывает:

• HMIS — модуль госпитального менеджмента, охватывающий EMR, лабораторию, финансы, аптеки и т.д.
• Occhiolino — LIMS, управляющий лабораторными анализами и образцами.
• MyGNUHealth — персональное приложение для ведения собственного здоровья и взаимодействия с медучреждениями.

Всё это работает поверх PostgreSQL и использует стандарты GNU Health, включая FHIR и HL7. Проект ведётся сообществом и врачами по всему миру, а не только кодом — в него встроены механизмы социальной медицины и анализа социально-экономических детерминантов здоровья.

• Пользователи обсуждают, что вместо дорогих проприетарных систем здравоохранения, можно использовать полностью open-source стек, включая собственную систему электронных медицинских записей (EHR), и что это может быть уже используется кем-то.
• Обсуждается, что коммерческие системы здравоохранения стоят непомерно дорого, но при этом малые клиники и практики не имеют технических ресурсов, так что "ценность" этих систем заключается в обслуживании и поддержке, а не в самом ПО.
• Участники обсуждают, что вместо того, чтобы тратить огромные суммы на проприетарные системы, можно было бы инвестировать в развитие open-source решений, которые могли бы быть использованы в госпиталях и клиниках, и что это может быть уже используется в развивающихся странах.
• Участники также обсуждают, что вместо того, чтобы продолжать использовать проприетарные системы, которые не предоставляют никакой ценности, кроме как для выставления счетов, можно было бы вместо этого инвестировать в развитие открытых стандартов, которые могли бы быть использованы в госпиталях и клиниках.
• Участники также обсуждают, что вместо того, чтобы продолжать использовать проприетарные системы, которые не предоставляют никакой ценности, кроме как для выставления счетов, можно было бы инвестировать в развитие открытых стандартов, которые могли бы быть использованы в госпиталях и клиниках.

Выпуск Litestream v0.5.0 знаменует переход от простого резервного копирования к эффективному восстановлению на определённый момент времени (PITR). Ключевое нововведение — формат LTX, позаимствованный из проекта LiteFS. Вместо потоковой передачи отдельных страниц базы данных Litestream теперь группирует изменения в рамках транзакций, что значительно ускоряет восстановление после сбоя.

Формат LTX решает проблему "горячих страниц" — например, при частых вставках в таблицу с автоинкрементным ключом, когда изменения концентрируются на ограниченном числе страниц. Раньше Litestream обрабатывал каждую страницу отдельно, что замедляло процесс. Теперь транзакции записываются целиком, сокращая количество операций ввода-вывода и ускоряя восстановление. Это делает SQLite ещё более надёжным решением для полноценных приложений.

• Пользователи обсуждают сложности развертывания SQLite-приложений на Fly.io, включая проблемы с инициализацией и миграцией баз данных.
• Litestream получает положительные отзывы за простоту использования, низкую стоимость репликации в S3 и надежность как инструмента для резервного копирования и репликации.
• Обсуждаются технические детали Litestream: поддержка S3-совместимых хранилищ, условные записи для реализации временных lease и планы по реализации read-replicas через VFS.
• Участники сравнивают Litestream с другими решениями (LiteFS, rsync, управляемые БД), отмечая его операционную простоту и отсутствие необходимости в отдельном сервере.
• Поднимаются вопросы о практическом применении SQLite и Litestream: восстановление после сбоев, работа с нестабильным интернетом, целесообразность использования против PostgreSQL/MySQL для разных сценариев.

Выпущена стабильная версия Immich 2.0.0 — это крупное обновление платформы для самостоятельного хранения фотографий с открытым исходным кодом. Ключевые изменения включают переработанный интерфейс, улучшенную производительность и расширенную поддержку форматов медиа. Добавлены новые функции, такие как умные альбомы на основе ИИ, улучшенные инструменты поиска и более гибкие настройки приватности.

Проект активно развивается с фокусом на децентрализацию и контроль пользователей над данными. В обсуждениях подчёркивается рост сообщества и количество контрибьюторов, что говорит о востребованности альтернатив облачным сервисам. Версия 2.0.0 знаменует переход к более зрелой и надёжной платформе, готовой для повседневного использования.

• Пользователи высоко оценивают Immich как быструю, функциональную и удобную альтернативу Google Photos и iCloud для самостоятельного хостинга фотографий.
• Отмечаются некоторые недостатки: сложности с интеграцией внешних библиотек, частые обновления без значимых изменений, использование ресурсоемкой PostgreSQL и опасения по поводу стабильности.
• Обсуждаются пожелания по улучшению: расширенные возможности поиска по карте и времени, улучшенное управление дубликатами, более гибкая структура хранения и нативные решения для iOS.
• Часть пользователей ищет более простые, статические решения для публичного показа фотографий, не требующие авторизации.
• Команда разработчиков Immich получила похвалу за скорость развития и открытость, включая раздел «Cursed Knowledge» на сайте.

Redis показал заметно лучшую производительность по сравнению с Postgres при использовании в качестве кэша. В тестах на чтение Redis обрабатывал больше запросов в секунду, при этом нагрузка на CPU у сервера с Redis была умеренной (~1280mCPU из доступных 2000mCPU), а потребление памяти стабильно держалось на уровне ~3800 МБ. Сервер HTTP стал узким местом в случае Redis, исчерпав свои CPU-ресурсы.

Для Postgres основным ограничением стал CPU самой базы данных, который постоянно работал на максимуме. Это подтверждает, что Redis эффективнее справляется с высоконагруженными сценариями кэширования, особенно когда требуется низкая задержка и высокая пропускная способность операций чтения.

• Критика методологии бенчмарка: сравнение ненастроенных Postgres и Redis считается некорректным, так как Postgres требует тонкой настройки под железо для серьёзных тестов.
• Сомнения в целесообразности использования Postgres как кэша: отсутствие встроенного TTL, нагрузка на основную БД и сложности с вакуумом делают Redis более надёжным решением.
• Подчёркивается важность контекста: для небольших нагрузок (<1000 RPS) и упрощения стека использование Postgres может быть оправдано.
• Замечания о специфике теста: сравнение ограниченного Postgres (2 ядра) с неограниченным Redis, малый размер данных и отсутствие пайплайнинга искажают результаты.
• Обсуждаются альтернативы: использование UNLOGGED таблиц, специализированных клиентов (rueidis) или встроенного кэша приложения вместо распределённого решения.

PlanetScale запустил общедоступную версию своей управляемой базы данных для Postgres, завершив этап приватного тестирования. Сервис предлагает миграцию с других провайдеров Postgres через гайды и поддержку sales-команды для сложных случаев. Компания уже пять лет развивает Vitess для MySQL, а теперь переносит этот опыт на Postgres, объединяя производительность своей платформы Metal с гибкостью Postgres.

Сотни компаний, включая Convex и Supermemory, уже используют PlanetScale для Postgres в продакшене, отмечая улучшение скорости и масштабируемости. Анонсирован также будущий инструмент Neki — решение для шардинга Postgres, построенное на принципах Vitess, но спроектированное с нуля для специфики Postgres; его открытую версию планируют выпустить позже.

• Успешная миграция на PlanetScale Postgres с улучшением производительности запросов и оперативной поддержкой команды, включая помощь в решении возникших проблем.
• Критика недостаточной ясности описания продукта и цен на сайте для новых пользователей, а также отсутствия бесплатного тарифа для тестирования.
• Вопросы о технических деталях: масштабировании записи (горизонтальное шардирование через Neki), использовании эфемерных дисков NVMe в GCP, поддержке расширений Postgres и сравнении с конкурентами (Aurora, Supabase).
• Положительные отзывы от пользователей бета-тестирования о высокой производительности и надежности продукта в production-среде.
• Объяснения от команды PlanetScale о архитектуре (репликация для надежности вместо сетевых дисков) и планах по развитию (горизонтальное масштабирование через Neki).

Как работает «свинобойка»

1. Крючок – случайное СМС/мессенджер: «Привет, Анна?» → жертва отвечает.
2. Сборка личности – 5-7 дней лёгкого флирта/дружбы; выясняют доход, семью, кредитку.
3. Платформа-ловушка – переводят в WhatsApp/Signal, сбрасывают ссылку на «криптобиржу» (поддельная).
4. Первый кэш-аут – просят внести $100-500, показывают +20 % прибыли за 2 дня.
5. Откармливание – «эксклюзивный пул», «контракт с ограниченным входом»; жертва несёт кредитки, займы, продаёт авто.
6. Нож – когда вклад >$50 k, счёт «замораживают» под предлогом налога/маржи; требуют ещё.
7. Исчезновение – чат удаляют, сайт закрывают, номер выбрасывают. Средний цикл: 40-60 дней.

Цифры

• 75 % пострадавших – мужчины 30-55 лет.
• Средний убыток: $180 тыс. (макс. в кейсе – $2,3 млн).
• 60 % денег выводится через Tether на биржи без KYC за 12 минут.
• 1 оператор ведет 8-12 «свиней» одновременно.

Схема техов

• SIM-банки + Google Voice для спуфинга.
• Фейковые биржи клонируют MetaTrader; баланс правят в Postgres.
• Обнал через DeFi-миксеры (Tornado, Railgun) → китайские овер-де-Каунтеры → юань наличными.

Признаки

• Незнакомец пишет первым, фото украдено у модели.
• Речь о «внутреннем сигнале» или «арбитраже USDT».
• Сайт младше 3 месяцев, SSL от Cloudflare, домен .vip/.top.
• Прибыль ровно 18-22 % в неделю.

Что делать

• Проверьте номер/фото через Yandex/Google Images.
• Любая «инвестиция» в Telegram = красный флаг.
• Сообщите банку о мошенничестве в течение 24 ч – 30 % шанс вернуть часть.

• Пользователи обсуждают "scam с разделкой свиней" — многоэтапные мошеннические схемы, где жертв ("свиней") сначала "откармливают", выстраивая доверительные отношения в течение нескольких месяцев, а затем "забивают", выманивая крупные суммы, часто через фейковые криптоинвестиции.

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

• Жертвами становятся не только пожилые или уязвимые люди, но и молодые, образованные individuals, включая инженеров. Ключевой фактор — не интеллект, а эмоциональная уязвимость или одиночество в данный момент жизни.

• Масштабы проблемы колоссальны: с 2020 года похищено около $75 миллиардов, а индустрия кибермошенничества по доходам сравнялась с незаконной торговлей наркотиками.

• Обсуждение также затрагивает необходимость обучения в школах распознаванию мошенничества, сложность борьбы с этими схемами из-за их跨境ного характера и этические аспекты самого термина, который может усиливать чувство вины у жертв.

Amazon S3 Vectors: убийца или спаситель векторных БД?

AWS запустил S3 Vectors — хранилище эмбеддингов прямо в S3. Цена низкая, интеграция в экосистему AWS очевидна. Кто-то уже похоронил специализированные векторные СУБД вроде Milvus, Pinecone, Qdrant. На деле — не так.

Почему это не конец векторных БД

1. Стоимость поиска может быть выше, чем вызов LLM. У одного AI-стартапа расходы на векторный поиск в 2× превышают счёт за OpenAI.
2. RAG вырос до миллиардов векторов за ночь. С3 не масштабируется до таких размеров без потери скорости и точности.
3. Latency-требования изменились, но не исчезли. Пока LLM генерирует ответ, можно подождать 100 мс, но не 5 с.

Что умеет S3 Vectors

• Простой knn через REST / SQL-подобный язык.
• Хранит векторы рядом с объектами, без отдельного кластера.
• Цена: ≈ 0,32 $/млн запросов + стандартные тарифы S3.

Чего нет

• GPU-ускорения, HNSW, PQ, динамического индексирования.
• Фильтрация по метаданным на лету.
• Горизонтального масштабирования под высокую QPS.
• SLA на latency и точность.

Где пригодится

• Холодный архив, редкие запросы, прототипы.
• Совместная работа с полноценной векторной БД: S3 держит дешёвую «копию всего», а hot-слой (Milvus/Pinecone) — быстрый доступ к топ-N.

Итог
S3 Vectors — ещё один кирпичик в стеке, а не замена. Специализированные СУБД остаются единственным способом получить миллиардные индексы, фильтры и суб-100 мс latency без компромиссов.

• S3 Vectors — это дёшево и сердито: холодное хранилище, top-k ≤ 30, фильтры после поиска, нет гибридного поиска и нормальной документации.
• Подходит лишь для низких QPS и «холодных» данных; для рекомендаций, высокого top-k или сложных фильтров придётся шардировать или выбирать другой продукт.
• Цена растёт ступенчато: одна «квантовая» добавка в фильтре может удвоить счёт; у некоторых компаний поиск стоит дороже, чем вызовы OpenAI.
• Альтернативы: Turbopuffer, LanceDB, Cloudflare Vectorize, pgvector в Postgres — каждый даёт больше контроля, функций и/или дешевле при миллионах векторов.
• AWS не раскрывает внутренности, поэтому сообщество тратит дни на реверс-инжиниринг; при превью-ограничениях производительность может вырасти, но гарантий нет.

%CPU — обманка
Система показывает 50 % загрузки, но реально сервер выполняет 60–100 % максимально возможной работы.

Эксперимент
Ryzen 9 5900X (12 ядер / 24 потока), Turbo включён.
Скрипт запускал stress-ng двумя способами:

• 24 потока по 1–100 % нагрузки;
• 1–24 потока по 100 %.

Результаты

• Общий CPU-тест: при 50 % «утилитой» реальная работа 60–65 %.
• 64-битная математика: 65–85 %.
• Умножение матриц: 80–100 %.

Почему так

1. Hyper-threading: после 12 потоков «ядра» делят ресурсы, прирост стремится к нулю.
2. Turbo: частота падает с 4.9 до 4.3 ГГц при росте загрузки, поэтому «утил» растёт быстрее реальной работы.

Вывод
Полагаться на линейный рост %CPU — ошибка. При эффективной загрузке (>50 %) показания занижены, и различия между процессорами могут быть огромными.

• Участники сходятся во мнении, что «%CPU» — это не ложь, а линейная мера нелинейной реальности: SMT, Turbo, общие ресурсы и ожидание памяти делают 60 % «загрузки» фактически пределом.
• Практики SRE подтверждают: модели очередей по CPU% работают лучше «старой мудрости», но только если понимать, что 50–60 % уже «почти всё».
• Несколько человек вспомнили, как менеджеры требовали «увеличить сервер», увидев 100 %, хотя процессор простаивал в busy-wait или ждал I/O.
• Подчёркивается, что IPC, latency, power-draw и прямое нагрузочное тестирование приложения дают более точную картину, чем сырые проценты.
• Утилита stress-ng удобна для синтетики, но не для production-бенчмарков; реальные приложения (Postgres, Memcached) ломаются раньше, чем показывает 100 % CPU.

Один большой сервер вместо оркестра микросервисов

Современный сервер Azure с двумя AMD EPYC 3-го поколения даёт:

• 128 физических ядер / 256 потоков
• до 8 ТБ ОЗУ, 200 ГБ/с пропускная способность
• 128 линий PCIe 4.0 → 30 NVMe + 100 Гбит/с сеть
• 4 TFLOPS — в 2000 г. хватило бы для первой строчки Top500

Что он умеет

• 800 Гбит/с видео (Netflix)
• 1 млн IOPS в NoSQL, 70 k IOPS в PostgreSQL
• 500 k RPS nginx, компиляция ядра Linux за 20 с, кодирование 4K-видео 75 fps

Сколько стоит

• Аренда:
  – OVH: 128 ядер, 512 ГБ ОЗУ, 50 Гбит/с — $1 318/мес.
  – Hetzner: 32 ядра, 128 ГБ — €140/мес.
  – AWS m6a.metal: 96 ядер, 768 ГБ — $6 055/мес.
• Покупка: ~$40 000 за аналогичную конфигурацию у Dell.

Вывод
Для большинства задач один такой сервер перекрывает потребности всей компании. Распределённые системы нужны редко; чаще достаточно «одного большого сервера» и простого деплоя.

• «Облачный налог» заставляет инженеров выбирать только дорогие облачные решения, хотя за $200/мес. у Hetzner можно взять 48 ядер и 128 ГБ ОЗУ, тогда как AWS даёт лишь 4 vCPU и 16 ГБ.
• Многие участники подтверждают: при стабильной нагрузке гибрид «colo + VPS» или одна большая машина дешевле и проще, чем микросервисы и K8s.
• Ключевые риски: единая точка отказа, необходимость админов и железных рук; зато нет «meta-слоёв» Docker-proxy-nginx и можно выжимать максимум из железа.
• Часть команд тратит годы на «cloud-native» пайплайны и закрывается, не успев выйти на рынок; проще начать с PaaS/Hetzner и переезжать, когда счёт действительно больно.
• Для критичных задач достаточно двух физических серверов (active/backup) и CDN; 99,9 % доступности хватает большинству бизнесов, которым на деле не нужен 100 % uptime.

Synology раньше нравился, теперь — нет.
Использую DS920, DS418 и DS1522, но новых больше не куплю.

Почему?

• Искусственное ограничение Samba. На новых моделях встроенный обвязчик жёстко режет число одновременных подключений.
• Жёсткая привязка к своим дискам. С 2025 г. NAS отказываются работать с любыми винчестерами, кроме продаваемых самой Synology. Гарантия у их дисков — 3 года, у WD Black — 5.

Куда дальше?
Собрать TrueNAS-сервер или посмотреть UGREEN, Buffalo и других.

• Пользователи жалуются на устаревшее ПО в новых Synology: старые ядра, EOL-версии PHP, PostgreSQL, Samba и др.
• Критикуют политику «только наши диски» и закрытость системы; многие называют это «выжиманием денег».
• Бывшие фанаты признают: раньше «включил и забыл», теперь — vendor-lock и упадок качества.
• Активно обсуждаются альтернативы: самосбор на TrueNAS/Unraid, UNAS Pro от Ubiquiti, TerraMaster, ASUSTOR, обычный Linux-сервер.
• Общий вывод: Synology теряет лояльность энтузиастов; кто готов потратить время, уходит на DIY-решения.

Databricks привлекает раунд Series K при оценке >$100 млрд.
Компания, предоставляющая платформу для аналитики и ИИ, подтвердила переговоры о новом финансировании. Сумма сделки и имена инвесторов пока не раскрываются, но источники называют ориентир выше $100 млрд. Это почти вдвое превышает оценку в $62 млрд, полученную в сентябре 2023 года.

По данным Bloomberg, Databricks выручила за последние 12 месяцев $2,4 млрд, рост 50 % г/г. Компания планирует выйти на IPO в 2025 году.

• Databricks объявил о раунде Series K на $10 млрд при оценке $100 млрд, вызвав волну скепсиса: многие считают это попыткой отложить IPO и избежать реальной оценки.
• Участники обсуждения подчеркивают, что компания за 15 лет и $10+ млрд всё ещё не прибыльна, а продукт (Spark, «обёртки» над Postgres, Lakehouse) кажется переоценённым и дорогим.
• Пользователи жалуются на высокие расходы, долгий запуск задач и сбои в сервисе; конкуренты вроде Snowflake выглядят дешевле.
• Раунд воспринимается как способ «разогнать» оценку и дать ликвидности ранним инвесторам, а не как финансирование роста.
• Сравнения с WeWork, Palantir и OpenAI подчеркивают, что длинные цепочки раундов уже не редкость, но вызывают опасения по поводу «пузыря ИИ».

CodeRabbit: от PR до RCE и доступа к 1 млн репозиториев

CodeRabbit — самое популярное AI-приложение на GitHub Marketplace (1 млн репозиториев, 5 млн PR). При установке он анализирует каждый PR и оставляет AI-комментарии.

Найденные уязвимости

1. RCE через Markdown-рендеринг

   • Внутри контейнеров запускается markdown-it с плагином markdown-it-katex.
   • Плагин использует child_process.exec без фильтрации LaTeX-ввода.
   • Внедрённый в PR $\input{/etc/passwd}$ запускает произвольные команды.

2. Утечка токенов

   • Внутри контейнеров доступны переменные окружения: GITHUB_TOKEN, CODERABBIT_API_KEY, DATABASE_URL.
   • Чтение /proc/self/environ и ~/.netrc позволило получить токены GitHub, JWT-секреты и строку подключения к PostgreSQL.

3. Доступ к 1 млн репозиториев

   • Установленный GitHub-App имеет scope contents:write во всех подключённых репозиториях.
   • С помощью украденного токена можно клонировать/писать в приватные репы, создавать PR, коммиты и релизы.

Цепочка атаки

1. Создаём PR с вредным LaTeX.
2. Получаем RCE в контейнере CodeRabbit.
3. Считываем секреты.
4. Используем токен GitHub для полного доступа к репозиториям.

Меры защиты

• Переход на изолированные sandbox-среды.
• Отключение опасных LaTeX-функций.
• Минимизация scope GitHub-токенов.

• Исследователи нашли RCE в CodeRabbit: Rubocop запускался в проде без песочницы, позволяя выполнять любой код и получить ключи GitHub-приложения.
• Уязвимость дала доступ на запись к ~1 млн репозиториев; компания утверждает, что «данных клиентов не скомпрометировано», но аудита нет.
• Пользователи критикуют отсутствие прозрачности, грубые ошибки в управлении секретами (ключ в ENV) и чрезмерные права GitHub-приложений.
• Главный вывод: анализаторы кода должны запускаться в изолированных средах без доступа к чувствительным переменным, иначе подобные инциденты неизбежны.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.