Hacker News Digest

Neki — шардированный Postgres от создателей Vitess.
Vitess уже масштабирует MySQL для сотен тысяч пользователей; теперь та же мощь переходит к Postgres.

Neki не форк Vitess. Мы строим с нуля, опираясь на опыт работы в экстремальных нагрузках, и откроем проект как open-source, когда он будет готов к самым требовательным задачам.

Следите за новостями и регистрируйтесь на neki.dev.

• Пользователи обсуждают анонс PlanetScale о «Vitess для Postgres», но код ещё не выложен, что вызывает скепсис.
• Всплывает конкуренция: Supabase уже работает над своим проектом Multigres, а автор Vitess, Сугу Сугумаран, теперь в Supabase.
• Вопросы о самостоятельном хостинге, необходимости шард-ключей и сравнении с YugabyteDB, CockroachDB и другими «PostgreSQL-совместимыми» решениями.
• Некоторые считают, что PostgreSQL устарел и нуждается в замене; другие отмечают, что сам PostgreSQL постоянно эволюционирует.

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.

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

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

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

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.

• Zitadel: JS-движок не поддерживает именованные группы в regex.
• Entra: PKCE есть, но не указан в OpenID-доке → клиенты думают, что нет.
• EXIF: размеры в метаданных могут не совпадать с реальными.
• YAML: пробелы ведут себя неочевидно.
• Windows: скрытые файлы нельзя открыть флагом "w"; опция SMB hide dot files усложняет жизнь.
• Git: автопреобразование LF ↔ CRLF ломает bash-скрипты.
• Cloudflare Workers: fetch по умолчанию использует http, даже если указан https.
• Android/iOS: без разрешения на геолокацию GPS-данные могут тихо удаляться из фото.
• PostgreSQL NOTIFY: работает в транзакции → WAL растёт каждые 5 с при использовании socket.io-адаптера.
• npm-скрипты: каждый запрос к реестру → плохой health-check.
• JS-«пакетный» спамер: добавляет 50 лишних зависимостей «для обратной совместимости».
• bcrypt: учитывает только первые 72 байта пароля.
• JS Date: годы и дни считаются с 1, месяцы — с 0.
• ESM ↔ CJS: до Node 20.8 смешанный импорт мог вызвать segfault.
• PostgreSQL: максимум 65 535 параметров — большие bulk-insert ломаются.
• Clipboard API и др. работают только в HTTPS/localhost.
• TypeORM: .remove() удаляет поле id из переданного объекта.

• Пользователи восторженно приняли идею «cursed knowledge» — каталога кошмарных нюансов, сопровождаемого коммитом-фиксом.
• Обсуждали PostgreSQL-лимит в 65 k placeholder’ов, причины появления 50 лишних npm-пакетов, скрытые потоки NTFS/ADS и «призрачные» файлы macOS.
• Упомянули, что bcrypt обрезает пароль до 72 байт, Cloudflare Workers могут игнорировать https, EXIF-даты в Immich — постоянная головная боль.
• Поделились личным опытом: неразрывные пробелы, case-insensitive имена в macOS, Java-классы в Oracle, «магия» YAML-парсеров.
• Кто-то предложил превратить подборку в репозиторий-«Awesome Cursed», другие подчеркнули пользу такого «терапевтического» лога ошибок.