Hacker News Digest

Команда Zed перешла на новую облачную инфраструктуру под названием Zed Cloud, построенную на Rust и WebAssembly через Cloudflare Workers. Это решение заменяет старый бэкенд Collab, использовавшийся с основания компании, и призвано снизить операционные затраты на обслуживание сервисов, позволив команде сосредоточиться на развитии основного продукта. Cloudflare Workers обеспечивает простое масштабирование, а такие сервисы, как Hyperdrive для Postgres, Workers KV для временного хранения и Queues для асинхронной обработки задач, обеспечивают необходимую функциональность.

В основе новой системы лежит фреймворк с трейтом Platform, позволяющий писать код независимо от платформы, сохраняя при этом доступ ко всем возможностям Cloudflare Workers. Для этого реализованы две платформы: CloudflarePlatform для работы в продакшене и локальной разработки, и SimulatedPlatform для тестирования, имитирующей практически все компоненты системы. Такой подход обеспечивает гибкость и тестируемость всей инфраструктуры Zed Cloud.

• Обсуждение в основном вращается вокруг трёх тем: использование WebAssembly в облачных сервисах, сравнение производительности и стоимости Rust vs JavaScript в Cloudflare Workers, и перспективы FOSS альтернатив.
• Участники обсуждают, что на данный момент Rust в WASM всё ещё имеет существенные накладные расходы по сравнению с нативным кодом, но при этом отмечается, что Cloudflare Workers и Supabase Edge Functions предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in.
• Также поднимается вопрос о том, что хотя WASM в браузере может и не достигает нативной скорости, он предоставляет беспрецедентную переносимость и безопасность, что делает его идеальным для серверлесс вычислений.
• Наконец, участники высказывают, что хотя Cloudflare и Supabase предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in, но всё ещё остаётся вопрос о том, какие именно преимущества предоставляет использование Rust в WASM в контексте редактора кода, если учесть, что большинство пользователей не будут замечать разницу в производительности, но при этом будут страдать от ограничений вендора.

Разработчики 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, и как это может повлиять на экосистему.
• Некоторые участники выражают обеспокоенность по поводу того, что это может быть слишком сложным для некоторых пользователей, и что это может быть дорогим для использования.

За десять лет автор прошёл путь от веб-разработчика до специалиста по базам данных, присоединившись к EnterpriseDB, где работает над pglogical и Postgres Distributed. Его карьера началась в 2014 году с JavaScript и Python, затем он стал менеджером инженеров. Прорывным моментом стало 2020 год, когда проблемы с производительностью его сервиса заставили его изучить индексы и структуры данных. Он создал образовательные проекты, включая простую in-memory SQL базу данных, и построил сообщества вроде Software Internals Discord и /r/databasedevelopment.

После неудачной попытки запустить собственный стартап в 2021-2023 годах и работы в TigerBeetle автор искал позицию именно разработчика баз данных, а не DevOps-инженера для работы с базами. Несмотря на нетрадиционный путь (он бросил колледж) и сомнения работодателей, он получил три предложения на работу над расширениями Postgres на C и Rust. Выбрав EnterpriseDB, компанию с 20-летней историей и одним из крупнейших вкладчиков в развитие Postgres, он предпочёл стабильность ранним стартапам, в которых работал последние три года.

• Сообщество обсуждает, как трудно сменить специализацию, если ты уже «записан» в базе данных как специалист в области X, и как это влияет на найм и карьерные возможности.
• Участники делятся личным опытом: кто-то ушел в разработку на C/C++ и Rust, кто-то перешел в SRE или DevOps, кто-то пытается попасть в компиляторы.
• Обсуждается, что рекрутеры и системы найма не видят за пределами ключевых слов в резюме и не учитывают site-reliability, DevOps и прочие смежные навыки, что делает смену специализации еще более сложной.
• Участники делятся советами, как обойти эту систему: делать сайд-проекты, которые демонстрируют навыки в новой области, участвовать в open-source, писать блоги и статьи, и так далее.
• Также обсуждается, что важно не только выждать подходящий момент, но и быть готовым пойти на уменьшение зарплаты и не бояться начать с более низкой позиции, что может быть ключом к переходу в новую область.

Armin Ronacher разработал библиотеку Absurd — решение для создания надежных рабочих процессов, использующее только Postgres без дополнительных сервисов. В ответ на растущий спрос на устойчивое выполнение (durable execution) в эпоху AI-агентов, он создал минималистичную систему на основе единственного SQL-файла. Библиотека решает проблему сохранения состояния при сбоях, используя возможности Postgres для управления очередями и хранения чекпоинтов. Ключевая особенность — деление задач на шаги, которые автоматически восстанавливаются после перезапуска, избегая дублирования работы.

Для AI-агентов Absurd предлагает элегантный подход с автоматической нумерацией повторяющихся шагов. Пример кода демонстрирует задачу с единственным шагом "iteration", которая при повторении превращается в "iteration#2", "iteration#3" и т.д., сохраняя только новые сообщения. Система поддерживает приостановку задач, ожидание событий и автоматическую загрузку состояния из чекпоинтов. Запуск осуществляется через простую функцию absurd.spawn(), а обработка ошибок включает механизм повторов с ограничением попыток.

• Обсуждение в основном вращается вокруг двух тем: длительное выполнение задач (durable execution) и инструментов для этого, таких как Absurd SQL и Temporal, а также их сравнение с другими решениями, включая DBOS и Cadence.
• Участники обсуждают, что такие инструменты как Absurd SQL и Temporal предоставляют простоту и надежность, но могут быть сложны в использовании и требуют дополнительной настройки.
• Также обсуждается, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• Участники также обсуждают, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• В конце обсуждение сосредотачивается на том, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.

• SQLite не поддерживает параллельную запись; WAL-режим лишь разрешает параллельное чтение, но не пишущие транзакции.
• Проблема SQLITE_BUSY чаще всего возникает из-за длительных транзакций, которые не закрывают файл, и не из-за реальной конкуренции за доступ.
• Не стоит забывать, что SQLite — это встроенная СУБД, а не серверная СУБД, и что она не предназначена для высоконагруженных веб-приложений.
• В отличие от PostgreSQL, MySQL и других серверных СУБД, SQLite не поддерживает параллельную запись, и поэтому не может быть использована в ситуациях, где требуется высокая параллельность.

Проект Pico-100BASE-TX представляет собой впечатляющее программное решение для микроконтроллеров Raspberry Pi RP2040 и RP2350, позволяющее им работать как передатчики Fast Ethernet со скоростью 100 Мбит/с. Реализация использует технологию "bit-banging" - программную передачу данных без специализированного оборудования, что является значительным техническим достижением. Проект включает в себя UDP фреймер для обработки сетевых пакетов, что делает его практически полезным для реальных сетевых приложений.

Разработчикам удалось преодолеть ограничения микроконтроллеров, реализовав высокоскоростную Ethernet-связь исключительно программными средствами. Это демонстрирует потенциал современных микроконтроллеров для сложных сетевых задач, открывая возможности для создания сетевого оборудования на базе недорогих плат Raspberry Pi. Проект особенно интересен энтузиастам IoT и разработкам, требующих высокоскоростной сетевой связи в компактном и экономичном исполнении.

• Пользователи жалуются на сложность работы с JSONB в PostgreSQL, особенно при извлечении данных из вложенных структур, требующих сложных запросов.
• Критикуется недостаточная понятность документации PostgreSQL по функциям работы с JSON, что затрудняет освоение для новичков.
• Отмечается, что встроенные функции JSONB в PostgreSQL мощны, но их синтаксис может быть неинтуитивным для простых задач.

В статье сравнивается использование 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 может быть более надежным и безопасным, особенно если уже используется для других целей.

Fly.io столкнулся с крупнейшим сбоей в истории 1 сентября 2024 года из-за ошибки в Rust-коде их системы распределенного состояния Corrosion. Ошибка в if let выражении над RWLock привела к мгновенному и "заразному" deadlock, который парализовал все прокси-серверы платформы. Авторы подчеркивают, что распределенные системы — это "усилители взрывов": они распространяют данные по сети, а вместе с ними — и ошибки в системах, зависящих от этих данных.

Эта катастрофа стала следствием архитектурных решений Fly.io. В отличие от Kubernetes с его централизованной базой данных, Fly.io использует децентрализованную модель, где серверы являются источником правды о своих рабочих нагрузках. Чтобы масштабироваться по всему миру, они перешли от HashiCorp Consul и SQLite-кэшей к собственной системе Corrosion. Авторы предупреждают: если распределенная система еще не испортила вам выходные или не заставила не спать всю ночь, вы еще не до конца ее понимаете.

• Баг с if let и RWLock в Rust приводил к мгновенному глобальному дедлоку, что вынудило перейти от единого кластера к региональной двухуровневой схеме данных.
• Использование cr-sqlite (CRDT SQLite) для согласованности вызвало проблемы с nullable-колонками и масштабируемостью, что привело к критике выбора SQLite вместо Postgres.
• Gossip-протокол (SWIM) показал ограниченную масштабируемость (~2K-3K узлов), что потребовало иерархической структуры и разделения на региональные кластеры.
• Дизайн блога и отсутствие дат в статьях вызвали нарекания, но технические решения (регионализация, отказ от мгновенного глобального состояния) признаны необходимыми.

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

Чтения и записи в PostgreSQL не равны по стоимости: чтение происходит 8kb блоками, часто из памяти, в то время как запись включает WAL, индексы, TOAST таблицы и требует больше ресурсов. Автор предлагает запрос для оценки соотношения чтения/записи на основе внутренних метаданных PostgreSQL, где по умолчанию используется соотношение 5:1 (чтение:запись).

• Обсуждение критикует статью за то, что она не сравнивает PostgreSQL с другими СУБД и не дает практических советов по тюнингу под конкретную нагрузку.
• Участники обсуждают, что статья не учитывает, что большинство приложений имеют смешанную нагрузку на чтение и запись, а не чисто чтение или запись.
• Некоторые комментаторы отмечают, что статья не упоминает OLTP и OLAP, что делает ее менее полезной для практического использования.
• Также обсуждается, что статья не дает ясного определения, что считается "read-heavy" или "write-heavy" в контексте 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 дня, что привело к потере данных.

Репозиторий sivers/sivers представляет собой личную базу данных автора и веб-приложения, которые её используют. Проект демонстрирует подход к созданию персональной информационной системы с открытым исходным кодом.

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

• Сторонники подхода "база данных как единственный источник истины" приводят примеры от 2007 года до сегодняшнего дня, показывая, что идея не нова, но вот вдохновение от неё пришло к Дереку Сиверсу, который в свою очередь вдохновил обсуждение на Hacker News.
• Обсуждение затрагивает вопросы от "что если вся логика в БД" до "какие ещё нестандартные инструменты могут подхватить эстафету", включая ссылки на PostgREST и Supabase как современные эквиваленты идеи.
• Участники делятся личным опытом, от 2007 года до сегодняшнего дня, подчеркивая, что подход был популярен в ранних 2000-х и что он до сих пор может быть применим для новых проектов.
• Поднимается вопрос о том, как и где хранятся шаблоны и как они попадают в ответы сервера, а также обсуждается использование таких инструментов как HTMX или Datastar для гидратации через гипермедиа.
• В конце концов, обсуждение сводится к тому, что идея остаётся актуальной, и участники выражают надежду, что она может вдохновить следующего поколения разработчиков так же, как это сделал Rich Hickey со своим докладом "Simplicity Matters".

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

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

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

PostgreSQL 18 представил новую опцию конфигурации io_method, дающую пользователям больше контроля над обработкой дискового ввода-вывода. В отличие от версии 17, где использовались только синхронные запросы, в 18 доступны три режима: sync (старое поведение), worker (новый стандарт по умолчанию с фоновыми процессами) и io_uring (асинхронный интерфейс Linux для чтения с диска).

В ходе тестирования с использованием sysbench на базе данных размером ~300 GB на различных конфигурациях EC2 были получены неожиданные результаты. При одиночном подключении и сетевых хранилищах (gp3, io2) версии 18 в режимах sync и worker показали производительность выше, чем 17 и 18 с io_uring. Полные результаты для высококонкурентных сценариев и быстрых NVMe-накопителей еще ожидаются.

• Обсуждение подтвердило, что при использовании локального NVMe диска разница между 17 и 18 версиями PostgreSQL незначительна, но при этом сетевое хранилище всё ещё сильно уступает по производительности.
• Участники отметили, что важно понимать, что при использовании облачного хранилища вы платите не за IOPS, а за то, чтобы кто-то другой имел дело с резервным копированием, репликацией и обслуживанием оборудования.
• Также было отмечено, что в настоящее время PostgreSQL не поддерживает прямой ввод/вывод, но над этим ведётся работа.
• Были высказаны опасения, что использование VPS с локальным диском может повлечь за собой вопросы надёжности, так как такие диски, как правило, не имеют избыточности.
• В контексте обсуждения также поднялся вопрос о том, что влияние на производительность может оказать использование или отсутствие расширения, такого как TimescaleDB.

Проект JIT-компилятора для PostgreSQL сталкивается со сложностями из-за особенностей современных процессоров. Автор объясняет, что даже хорошо написанный интерпретатор может проигрывать в производительности из-за непредсказуемости переходов в switch-based интерпретаторах.

Используя технику "computed gotos" (динамических переходов), можно значительно ускорить интерпретацию, сделав шаблоны переходов более предсказуемыми для предсказателя ветвления процессора. Это может дать до 15-20% прироста производительности.

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

Кроме того, автор отмечает, что оптимизация под современные процессоры (особенно с их out-of-order исполнением и предсказанием ветвлений) требует осторожного подхода. Например, код должен быть структурирован так, чтобы минимизировать зависимости по данным и максимизировать параллелизм на уровне инструкций.

В итоге, проект направлен не только на создание JIT-компилятора, но и на то, чтобы переосмыслить, как должен работать интерпретатор, чтобы эффективно использовать современные процессоры.

• Обсуждение затронуло ограничения JIT в iOS из-за политики Apple, что влияет на производительность и возможности использования JIT в этой системе.
• Участники обсудили, что JIT-компилятор может быть полезен для оптимизации, но его отсутствие в iOS ограничивает возможности приложений.
• Также обсуждались различные аспекты производительности интерпретатора и JIT, включая влияние на предсказание переходов и спекулятивное исполнение.
• Участники упомянули, что JIT может быть полезен для DSL или других специализированных языков, но ограничения iOS могут затруднить это.

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

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

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

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

pgEdge выпустил open-source-утилиту spock — логическую репликацию PostgreSQL с поддержкой multi-master. Проект позиционируется как замена Bucardo и Slony, но с фокусом на высокую доступность и отказоустойчивость. Под капотом — использование логической репликации, что позволяет конфликтам разрешаться на уровне транзакции, а не на уровне отдельных запросов. Это делает spock пригодным для кластеров, где каждая нода может принимать запись.

Проект написан на C и Python, распространяется под лицензией PostgreSQL. Поддерживает PostgreSQL 12-16 и требует расширение pglogical.

• Разработчики подчеркнули, что multi-master репликация не обеспечивает такую же строгую согласованность, как PostgreSQL, и что это важно учитывать при выборе решения.
• Участники обсуждали, что при использовании multi-master репликации важно понимать, какие именно edge cases могут возникнуть и как они решаются.
• Были упомянуты такие решения, как CockroachDB и pgEdge, и обсуждались их плюсы и минусы по сравнению с другими решениями.
• Также обсуждались вопросы лицензии и лицензионной политики, а также то, какие именно ограничения могут быть связаны с использованием таких решений.
• В конце обсуждения было отмечено, что важно понимать, что multi-master репликация не решает всех проблем масштабирования и что важно тщательно оценивать, подходит ли она для конкретного use case.

PGLinter — это инструмент для анализа качества базы данных PostgreSQL, который выявляет проблемы с производительностью, безопасностью и стандартизацией. Он работает на основе настраиваемых правил, которые можно включать или отключать, и поддерживает экспорт результатов в стандартном формате SARIF для интеграции с CI/CD.

Ключевые возможности:

• Автоматическое выявление проблем: Отсутствующие индексы, неиспользуемые индексы, неправильные настройки безопасности
• Глубокая интеграция с PostgreSQL: Реализован как расширение, поэтому использует внутренние механизмы СУБД
• Гибкая настройка: Можно отключать отдельные правила, менять пороги срабатывания
• Удобство для разработчиков: Встраивается в CI/CD, есть санитизация схемы данных

Например, правило B001 выявляет таблицы без первичного ключа. T003 находит индексы, которые полностью дублируются другими индексами. C001 предупреждает, если настройки памяти небезопасны.

Пользователи могут запускать анализ через SQL: SELECT pglinter.perform_base_check(); или экспортировать результаты в SARif для интеграции с GitHub Actions, Jenkins и другими инструментами.

Проект активно развивается, с планами по добавлению правил, связанных с безопасностью, и расширением покрытия различных аспектов базы данных. Конечная цель — сделать PGLinter таким же обязательным в проекте, как ESLint для JavaScript или RuboCop для Ruby.

• Инструмент анализа БД pg_linter представляет собой расширение PostgreSQL, что вызывает вопросы о необходимости именно расширения, а не отдельного инструмента, который можно было бы запускать против любой БД.
• Участники обсуждения отмечают, что в 2025 году принцип наименьших привилегий в контексте безопасности и стабильности системы особенно важен, и устанавливать сторонние расширения в продакшен средах может быть неприемлемо.
• Некоторые участники высказывают мнение, что вместо расширения мог бы подойти и инструмент, который мог бы анализировать дамп базы данных либо имитировать схему в контейнере.
• Также обсуждается, что правила вроде B006 (таблицы с именами в верхнем регистре) могут быть неуместны в контексте конкретной ORM или обстоятельств, и что некоторые правила могут быть неприменимы к специфическим ситуациям, таким как TimescaleDB.

Parrot — это библиотека для языка Gleam, предоставляющая типобезопасный способ написания SQL-запросов. Она позволяет компилировать запросы на этапе разработки, выявляя ошибки в синтаксисе или типах данных до выполнения кода, что повышает надёжность приложений.

Библиография использует встроенные возможности Gleam для генерации корректного SQL, избегая распространённых проблем вроде опечаток в именах колонок или несоответствия типов. Это особенно полезно в проектах, где важна строгая статическая проверка и минимальное количество runtime-ошибок.

• Участники положительно оценивают sqlc и его порт для Gleam, отмечая преимущества использования чистого SQL с типобезопасностью.
• Обсуждаются ограничения SQL и ORM, в частности проблема композиции и динамических запросов, а также сравнение с другими инструментами (Kysely, PRQL, Django ORM).
• Несколько пользователей спрашивают, что такое Gleam, и получают разъяснения, что это типобезопасный язык для Erlang VM.
• Поднимается вопрос о кроссплатформенности запросов и поддержке разных СУБД, на который автор отвечает, что это зависит от возможностей sqlc.
• Сравниваются системы типов Gleam (статическая) и Elixir (gradual), отмечаются их ключевые различия и предпочтения.

Выпуск 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» на сайте.

ChartDB — это инструмент для визуализации схем баз данных, который помогает разработчикам и аналитикам лучше понимать структуру данных. Он автоматически генерирует интерактивные диаграммы на основе существующих баз данных, поддерживая популярные СУБД, такие как PostgreSQL, MySQL и MongoDB. Это упрощает проектирование, документирование и совместную работу над сложными системами.

Среди ключевых возможностей — автоматическое обновление схем при изменениях в БД, экспорт в форматы PNG или SVG, а также интеграция с инструментами вроде Git для версионного контроля. Практический плюс: визуализация помогает быстро находить связи между таблицами, что ускоряет отладку и оптимизацию запросов.

• Представлен инструмент ChartDB с открытым исходным кодом для проектирования схем баз данных через текстовые промпты с визуализацией в виде ERD-диаграмм.
• Пользователи отмечают удобный интерфейс и потенциальную пользу для быстрого прототипирования, но критикуют читаемость соединений и отсутствие обсуждения для уточнения требований.
• Высказаны опасения по поводу стоимости бесплатного использования ИИ, точности генерируемых схем (в т.ч. устаревшая информация о СУБД) и способности инструмента масштабировать решения.
• Отмечено, что многие ИИ-инструменты и так умеют работать с БД, генерировать SQL и диаграммы, поэтому ценность ChartDB видится в автоматизации и удобстве.
• Запросы на дополнительные функции: предпросмотр миграций, генерация SQL-запросов под use case, интеграция веб-интерфейса и расширение на проектирование классов.

DBOS Transact для Go — это фреймворк для оркестрации устойчивых рабочих процессов, использующий PostgreSQL как единый источник истины. Он позволяет писать транзакционные приложения на Golang, где бизнес-логика выполняется атомарно и изолированно, а состояние автоматически сохраняется в базе данных. Это устраняет необходимость в отдельных системах управления состоянием или очередях, упрощая архитектуру и повышая надёжность.

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

• Сравнение с Temporal и другими системами оркестрации рабочих процессов, обсуждение подхода DBOS как библиотеки против внешнего сервиса, вопросы об идемпотентности и гарантиях обработки событий.
• Вопросы о технических особенностях DBOS: масштабируемость в кластере, версионирование рабочих процессов, приоритизация заданий, безопасность и варианты развертывания без исходящего сетевого доступа.
• Обсуждение архитектурных решений и альтернатив, таких как pgglow, и их интеграция с Postgres и клиентами на разных языках.
• Связь проекта с академическими исследованиями (DBOS OS) и его дальнейшее развитие, включая планы по поддержке новых языков и функциональности.
• Реакция сообщества: от положительных отзывов о простоте модели до скептических вопросов о гарантиях и практическом применении, а также упоминание частоты постов о проекте.

В PostgreSQL 18 появилась поддержка асинхронного ввода-вывода (AIO), что позволяет эффективнее использовать хранилище. Основные параметры для настройки — io_method и io_workers. По умолчанию io_method = worker использует пул процессов для выполнения операций ввода-вывода, что обеспечивает кроссплатформенность и стабильность. Альтернатива io_uring эффективнее, но работает только на Linux и может быть недоступна в некоторых контейнерах из-за проблем безопасности.

Значение io_workers = 3 слишком консервативно для серверов с большим количеством ядер. Рекомендуется увеличивать его пропорционально числу CPU, особенно для интенсивных рабочих нагрузок. Например, на системе с 64 ядрами можно установить 16–32 воркеров. Важно тестировать настройки под конкретную нагрузку, так как универсального решения нет.

• Ожидание тестирования новой функции async I/O на базах данных в Azure с использованием ZFS для повышения производительности последовательного сканирования.
• Обсуждение выбора метода worker по умолчанию вместо io_uring из-за его универсальности и проблем безопасности с io_uring в некоторых средах.
• Вопрос о причинах более низкой производительности io_uring в сравнении с worker в некоторых бенчмарках и является ли это ошибкой или ограничением технологии.
• Дебаты о целесообразности использования CoW-файловых систем (например, ZFS, btrfs) для Postgres и сжатия на уровне ФС против встроенного сжатия СУБД.
• Уточнение, что новая функция async I/O сейчас применяется только для последовательных и bitmap-сканирований, но не для индексных.

PostgreSQL 18 добавляет нативную поддержку UUID v7 через функцию uuidv7(), что позволяет использовать UUID в качестве первичных ключей без потери производительности благодаря их последовательной природе. Это устраняет необходимость в сторонних расширениях или реализации генерации на уровне приложения.

Также введены VIRTUAL generated columns — теперь вычисляемые столбцы по умолчанию генерируются при чтении, а не записи, что экономит место на диске и избегает перезаписи таблиц при их добавлении. Эти изменения упрощают разработку, делая работу с базой данных более гибкой и эффективной.

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

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).

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

Хотя размер UUID остаётся 128-битным (больше, чем INT или BIGINT), современные CPU эффективно обрабатывают такие значения через SIMD-инструкции. Важно использовать бинарное представление UUID, а не строковое, для оптимизации производительности. UUIDv7 также подходит для публичных идентификаторов, так как их сложно угадать, в отличие от автоинкрементных чисел. Это делает его идеальным выбором для шардированных баз данных и сред с минимальной серверной координацией.

• Обсуждаются проблемы безопасности UUIDv7 из-за экспозиции времени создания в публичных идентификаторах, что может упростить угадывание соседних записей.
• Предлагаются решения для сокрытия времени создания на границе API, например, преобразование UUIDv7 в UUIDv4 или шифрование временной метки.
• Отмечается, что 62 бита случайности в UUIDv7 при наличии лимита запросов обеспечивают достаточную безопасность для большинства веб-приложений.
• Поднимается вопрос о негативном влиянии UUID (по сравнению с последовательными целыми числами) на производительность БД из-за отсутствия оптимизаций для последовательных ключей.
• Утверждается, что безопасность не должна зависеть от формата первичного ключа, а проблемы угадывания ID указывают на ошибки в проектировании системы.

• Пользователи высоко оценивают надежность, масштабируемость и удобство разработки Trigger.dev, особенно отмечая функцию отложенных задач и режим разработки.
• Обсуждаются сравнения с конкурентами (Temporal, Inngest, Restate), где Trigger.dev выделяется как движок устойчивого выполнения с собственной инфраструктурой для запуска рабочих нагрузок.
• Подчеркивается выгодное ценообразование сервиса по сравнению с самостоятельным хостингом на VPS.
• Затрагиваются технические аспекты: использование CRIU для снапшотов, обработка ошибок и повторных попыток, безопасность и модели развертывания.
• Отмечается сильная поддержка со стороны основателей и активное сообщество в Discord.
• Пользователи интересуются интеграциями (например, с Supabase/Postgres) и возможностями использования в различных сценариях, не только AI.
• Обсуждается ориентация рынка на AI-агентов, хотя платформа универсальна и подходит для любых фоновых задач и рабочих процессов.
• Поднимаются вопросы о различиях с другими инструментами (Mastra) и потенциальных рисках при рефакторинге из-за автоматических повторных попыток.
• Представители Trigger.dev разъясняют архитектурные решения и планы на будущее, включая возможность запуска рабочих нагрузок на своей инфраструктуре.

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

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 миллиардов, а индустрия кибермошенничества по доходам сравнялась с незаконной торговлей наркотиками.

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

QGIS — бесплатная, открытая кроссплатформенная ГИС (Linux, Windows, macOS).

• QGIS хвалят как мощный, бесплатный и расширяемый заменитель ArcGIS: открывает мульти-ГБ TIFF, живёт на Linux, ставится из Conda.
• Пользователи черпают открытые данные (лидар, зоны затопления, границы участков), строят NDVI-карты ферм, анализируют PostGIS и визуализируют harvest-данные.
• Слабые стороны: «90-х» UI, крутая кривая обучения, медленный старт, нет нативной ARM/нотаризованной сборки под macOS (ждут v4).
• Экосистема шире: GDAL, PostGIS, Geoserver, Kepler/MapLibre, LizMap, MapStore и др.; QGIS лишь «интегратор» всех этих инструментов.
• В корпоративе ArcGIS всё ещё царит (40-50 % рынка, удобные группы/роли), но многие компании переходят на QGIS ради экономии и гибкости.

• В Debian 13 исчезли устаревшие зоны US/* (US/Eastern, US/Pacific и др.); они живут в отдельном пакете tzdata-legacy.
• Переход тихий: в релиз-ноутс ни слова, многие узнали об изменении, когда ПО перестало стартовать или сломались cron-задачи.
• Проблема касается не только Debian: GitLab, PostgreSQL, IB TWS, Racket- библиотеки и др. продолжают использовать старые имена.
• Фикс прост: apt install tzdata-legacy, либо заменить US/Zone на America/City во всех конфигах и базах.
• Спор в треде: кто виноват — Debian (не предупредил), IANA (удалил без шумихи) или сисадмины (20 лет не следили за backward)?

Rails + SQLite: новые способы уронить прод

SQLite встроен в процесс веб-сервера — нет отдельного демона, портов, сокетов; всё хранится в одном файле. Плюс: пропали ошибки подключения к БД. Минус: файл живёт в контейнере, а контейнеры пересоздают, и данные исчезают.

Правило 1: клади БД в персистентное хранилище (EBS, Fly Volumes, …) и включи снапшоты.

Правило 2: веб, кеш, очередь и джобы по умолчанию пишут в тот же файл. Удобно, но воркеры теперь должны видеть этот файл. Запускай воркеры в том же VM, либо разнеси данные по разным БД и настрой database.yml.

Правило 3: SQLite блокирует всю БД на время записи. Параллельные длинные запросы = таймауты. Держи транзакции короткими, используй PRAGMA journal_mode=WAL, synchronous=NORMAL, busy_timeout=5000.

Правило 4: бекапы. sqlite3 db.sqlite3 ".backup backup.sqlite3" — атомарно, без остановки сервиса. Крути каждый час и перед деплоем.

Плюсы:

• FTS5-индекс из коробки
• Мегабайты вместо гигабайтов RAM
• $14/мес на Fly.io при 1 млн запросов
• Нет Redis, Postgres, S3 — только Rails-контейнер

Итог: SQLite позволяет поднять pet-project за вечер, но требует новых привычек: персистентные диски, WAL, короткие транзакции, общий доступ к файлу. Соблюдай правила — и база не уйдёт в /dev/null.

• Автор статьи утверждает, что его сервис «Feed Your Email» возможен только благодаря SQLite, но не объясняет, почему именно SQLite, а не PostgreSQL/MySQL.
• Многие участники считают SQLite удобным для малонагруженных и внутренних приложений из-за простоты развёртывания и отсутствия отдельного процесса БД.
• Критики отмечают: при росте нагрузки появляются проблемы с бэкапами, масштабированием, единственным писателем и отказоустойчивостью, смывая преимущества.
• Часть разработчиков использует обёртки вроде Litestream, Turso или Cloudflare D1, чтобы добавить репликацию и горизонтальное масштабирование к SQLite.
• В сообществе Rails новый тренд — «по-умолчанию SQLite» для быстрого старта MVP, но опытные пользователи предупреждают о риске «выстрелить себе в ногу» при росте проекта.

Spiral: Data 3.0
Новая эпоха — машины потребляют и выдают данные петабайтами.
Postgres и Lakehouse были рассчитаны на человека: входы и выходы — килобайты.
AI-хранилище должно отдавать 4 млн изображений в секунду, иначе H100 простаивает 70 % времени.

Почему ломается стек
Parquet → Arrow → tensors → кэш → GPU: 5 лишних шагов, 10× память, 55 ч сети на 1 с GPU-нагрузки.
Мелкие файлы (100 КБ) убивают S3, эмбеддинги и картинки застревают в «мертвой зоне» 1 КБ–25 МБ.

Побочные эффекты

1. Цена/скорость: инженеры крутят ETL вместо обучения.
2. Безопасность: в угони скорости открывают S3 и сливают базы через MCP-коннекторы. Долг превращается в 10× технический долг.

Spiral = хранилище для машин

• Потоковое чтение петабайтов без распаковки.
• Поиск, сэмплы, случайные чтения за миллисекунды.
• Модель доступа «по-умолчанию закрыто» → безопасность не тормозит.

Результат
GPU загружен, инженеры пишут модели, а не пайплайны.

• Сайт красивый, но без технических деталей: это пресс-релиз нового формата Vortex и СУБД Spiral, а не продукт.
• Vortex — колонковый формат «для эры ИИ», обещает прямую разгрузку из S3 в GPU, минуя CPU и сетевые задержки.
• Критика: нет цифр, нет сравнений с Parquet/Lance/Delta, много маркетинга («AI-scale», 22 млн $ сид-раунда) и мало кода.
• Потенциальная польза — ускорение OLAP-пайплайнов обучения моделей, но вопросы к транзакциям, изменяемости и реальному бенчмарку остаются.

• pgEdge теперь полностью Open Source
  Все ключевые компоненты (репликатор Spock, расширения Snowflake и Lolor) перелицензированы с проприетарной «pgEdge Community License» на свободную PostgreSQL License (OSI-одобрена).

• Что это даёт
  Можно свободно скачивать, модифицировать и использовать в продакшене без ограничений; код лежит в GitHub-репозиториях проекта.

• Где взять
  Исходники: github.com/pgEdge (репо spock, snowflake, lolor).
  Готовые образы и поддерживаемые сборки: облако, контейнеры, VM на сайте pgEdge.

• Зачем
  Мультимастер-дистрибутивный Postgres с минимальной задержкой и высокой доступностью теперь доступен сообществу без vendor-lock-in.

• Лицензия PostgreSQL (OSI) воспринята как «настоящая» open-source, в отличие от «фейковых» лицензий.
• Пользователи рады открытию кода, но опасаются, что гиперскейлеры «разграбят» проект.
• Маркетинговое описание вызывает раздражение: неясно, что за продукт, и «async multimaster» критикуют за потерю консистентности.
• Опытные пользователи спрашивают о реальной надёжности PgEdge и делятся багами (SIGILL в pgvector, месяц без реакции).
• Документация требует passwordless sudo и SSH, что отпугивает многих.

Патент OrioleDB теперь свободен для сообщества Postgres.

• Supabase открыла патент на B+-tree-структуру под Apache 2.0, заявляя, что это «щит» против IP-исков.
• Критики называют предыдущую лицензию «poison pill»: лицензия прекращалась при судебном иске к Supabase.
• CEO Supabase признал ошибку, быстро перелицензировал OrioleDB на Apache 2.0 и готов даже отдать патент сообществу.
• Некоторые участники всё равно не доверяют: считают, что 99 % «новизны» взято из старых научных работ и что щит защищает только компанию.
• Практические вопросы: пока нет SERIALIZABLE-уровня, совместимость не со всеми расширениями, зато высокая производительность на запись.

## DOOMQL: шутер в чистом SQL

**Идея**  
- Всё состояние — в таблицах CedarDB  
- Картинка = стек VIEW с трассировкой лучей  
- Цикл — bash-скрипт, 30 FPS: `psql < game.sql`  
- Клиент — 150 строк Python: читает клавиши, SELECT’ит кадр  

**Схема (сокращённо)**  
```sql
config( move, turn, ammo_max … );  
map(x,y,tile);  
players(id,hp,ammo…);  
inputs(player_id,action);  
mobs(id,x,y,angle,type);  
sprites(id,texture,offset);

Рендер

1. rays — лучи от игрока, столкновения со стенами
2. walls — высота линии = 1 / distance
3. sprites — проекция по x, z-order
4. frame — UNION walls+sprites, строка = пиксель
5. hud — здоровье, ammo, миникарта в ASCII

Мультиплеер

-- добавить игрока  
INSERT INTO players VALUES(:id);  
-- чужие движения  
SELECT * FROM players WHERE id != :me;

Производительность

• 640×480 ≈ 30 кадр/с на ноутбуке
• CedarDB распараллеливает лучи между ядрами

Читерство

UPDATE players SET hp=100, ammo=99 WHERE id=my_id;

Вывод
База = готовый игровой сервер: транзакции дают согласованность, а SQL — ещё и консоль читов.

• Кто-то запустил мультиплеерный «Дум» на чистом SQL (CedarDB), и это вызвало волну «Krieger, ты с ума сошёл!»
• Половина комментаторов спорит: это всё-таки Doom или всё же Wolfenstein 3D без текстур
• Автор признаётся, что вдохновился DuckDB-DOOM и просто называет любой 2.5D-шутер «думоподобным»
• Кто-то видит в проекте хитрую рекламу CedarDB (PostgreSQL-совместимый HTAP), другие – новую игру в «а тьюринг-полно ли это?»
• Участники сравнивают с ASCII-Doom, pg_doom и мечтают о полноценной MMO, целиком живущей в базе данных

• Репо: шаблон для хранения и анализа данных в Org-mode
• Коммиты: 8, веток: 1, тегов: 0
• Файл: README.org

• Пользователи делятся лайфхаками: org-babel + TRAMP = SQL-запросы на удалённых серверах прямо из Emacs.
• «Бедный SQL-workbench»: писать запросы в .org, вывод писать в /tmp/query-result.org, смотреть результат в соседнем буфере.
• Секьюрити: пароли прячем в ~/.pgpass или PGPASSFILE, чтобы не светить их в org-файле.
• Org-mode превращает студенческие шаблоны в красивые PDF (LaTeX), преподаватели думают, что ты TeX-гений.
• Кто пришёл из Vim — советуют Spacemacs как мостик; кто хочет шарить календарь с не-технической половиной — ищут синхронизацию.

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 не раскрывает внутренности, поэтому сообщество тратит дни на реверс-инжиниринг; при превью-ограничениях производительность может вырасти, но гарантий нет.

Как я решил проблему распределённой очереди через 15 лет

В Reddit всё — голоса, комментарии, посты — сначала попадало в RabbitMQ, потом в базу.
Очередь давала горизонтальное масштабирование, шейпинг и cron, но падала: задача могла исчезнуть после взятия из очереди или при краше брокера. Нужны были долговечные очереди, сохраняющие состояние в Postgres.

Сегодня это реализуется через долговечные workflow: каждый шаг чек-поинтится в БД, задачи запускаются параллельно, при падении продолжаются с последнего сохранённого места.

• Пост вызвал спор: одни хвалят вводный уровень, другие ждут разбора «распределённой» сложности и конкретного решения.
• Критика: заголовок обещает «как я решил», но статья не формулирует проблему и не показывает шаги решения.
• Автор подменяет «очереди» «устойчивыми воркфлоу»; читатели считают, что это разные вещи.
• RabbitMQ 15-летней давности обвинили в отсутствии надёжного бэкапа состояния; Kafka, наоборот, приводят как пример «и быстро, и надёжно», но её обвиняют в перекладывании сложности на потребителя.
• Главная идея DBOS: устойчивость без внешнего координатора и без переписывания кода под async-рантайм.

• Шутка: глиняная табличка 3100 г до н. э. — «база данных» с 5000-летним аптаймом.
• Проверил, какие даты принимают MySQL, Postgres, SQLite:
  – MySQL: мин. 1000 г н. э.
  – Postgres/SQLite: 4713 г до н. э. (юлианский календарь).
• Пример: INSERT … '4713-01-01 BC'::date работает, 4714 г до н. э. — уже ошибка.
• Вопрос: как хранить ещё более древние даты (например, экспонаты Британского музея)? Текстом, эпохой, кастомным типом?

• Самая ранняя письменность — это не литература, а счёты и квитанции: глиняные таблички фиксируют выдачу зерна и другие транзакции ~3300 г. до н. э.
• Для музейных дат «около X» нет единого числового стандарта; хранят как текст либо диапазон «start/end», а сортировку и поиск делает прикладной код.
• PostgreSQL ограничен 4713 до н. э. технически (4-байтный Julian day), но SQLite и кастомные схемы позволяют любые тексты или большие целые.
• Подавляющее большинство записей погибло: дошедшие таблички — пример survivor bias; цифровые носители вряд ли протянут 5000 лет.
• Пиво/ферментация упоминаются как возможный первичный двигатель оседлости и учёта задолго до клинописи.

• Данные на странице IMDB иерархические: фильм → режиссёр, жанры, актёры → персонажи.
• Иерархия двунаправленная: фильм→актеры и актер→фильмы.
• Реляционная БД хранит всё в плоских таблицах; при выводе строим нужную иерархию.
• Ручная сборка — утомительна, это «объектно-реляционное несоответствие».

SQL не умеет выдавать структуру
Цель: JSON вида

{"title":"Baby Driver","director":["Edgar Wright"],"writer":["Edgar Wright"],
 "genres":["Action","Crime","Drama"],
 "actors":[{"name":"Ansel Elgort","characters":["Baby"]}, …]}

Пошаговые запросы:

-- название
SELECT primaryTitle FROM title WHERE tconst='tt3890160';

-- режиссёры
SELECT p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='director';

-- сценаристы
... AND pr.category='writer';

-- актёры
SELECT p.nconst, p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='actor';

-- персонажи
SELECT pc.nconst, pc.character
FROM title t
JOIN principal pr          ON t.tconst=pr.tconst
JOIN principal_character pc ON pr.nconst=pc.nconst
WHERE t.tconst='tt3890160';

Попытка объединить всё в один запрос даёт декартово произведение (режиссёры×сценаристы) и пропуск записей при отсутствии одной из ролей. Поэтому приходится делать множество отдельных запросов и собирать итоговую структуру на клиенте.

• Обсуждение крутится вокруг «объектно-реляционного несоответствия»: SQL хорошо хранит нормализованные данные, но плохо отдаёт их иерархически.
• Многие считают, что виноват сам язык: нет встроенных вложенных отношений, агрегация в JSON делается громоздко, JOIN-ы приходится «переделывать» в коде.
• Часть участников предлагает решать задачу внутри СУБД: Postgres-функции json_agg, LATERAL-подзапросы, денормализованные VIEW и «JSON-проекции».
• Другие уверены, что проблема надумана: деревья в SQL вполне строятся (adjacency list, nested sets, closure table), просто нужно знать приёмы; ORM и NoSQL лишь откладывают боль.
• Упоминаются альтернативные пути: GraphQL-слой поверх SQL, графовые СУБД, документные хранилища (MongoDB), event-sourcing с CQRS, но каждый имеет свои trade-off.

Бюджетная битемпоральная система на SQLite + Clojure

Автор: Адитья Атхалье, 14–15 июля 2025
Цель: «бедняцкая» реализация половины битемпоральной СУБД, удовлетворяющая «десятому закону Хендерсона».

---

Идея

Смешать SQLite с идеями из бухгалтерии, Clojure, Datomic, XTDB, Rama и Local-First, чтобы хранить факты и время двух видов:

• valid-time — когда событие произошло в реальности.
• tx-time — когда мы это узнали и записали.

---

Мир фактов и времени

• Сущность = полная история её жизни.
• Факт может быть истинным или ложным; при столкновении фактов нужны правила приоритета.
• Наблюдение ≠ реальность: база фиксирует не саму реальность, а наши заметки о ней.
• Материализованная реальность зависит от того, кто спрашивает и «когда» он спрашивает.

---

Архитектура

• Две маленькие VM: одна работает, вторая — резерв.
• Дёшевые диски для хранилища временных данных.
• Clojure: пространства имён и неизменяемость как главные инструменты.
• Trade-off: сложно спроектировать, но легко строить, запускать, поддерживать и обучать.

---

Подход

1. Храним каждое изменение как добавление нового факта (append-only).
2. Используем SQLite как простой, надёжный движок.
3. Через Clojure-обёртку реализуем:
   • вставку с двойной временной меткой;
   • «time-travel» запросы (as-of valid-time, as-of tx-time).
4. Ограничиваемся минимальной сложностью на уровне всей системы.

---

Итог

Получили «половину» битемпоральной СУБД: медленную, сырую, но дешёвую, понятную и пригодную для локального использования.

• XTDB и другие битемпоральные СУБД хвалят за возможность запросов «как было на дату X»; примеры из жизни — P&L за март по данным на 4 апреля.
• Некоторые участники уже годами реализуют похожее вручную: PostgreSQL + tstzrange, append-only-логи, триггеры, EAV-модель.
• Критика: Clojure-сообщество «герметично», а сама идея «fetch-as-of» кажется многим неинтересной.
• В крупных аналитических СУБД (ClickHouse, DuckDB, BigQuery, Snowflake, Spanner) AsOf-джоины уже доступны «из коробки».
• Автор блога пришёл к выводу: хранить всё как append-only-лог фактов и не плодить «две системы» (основная БД + аудит).

%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.

Кратко:
Инженеры, создающие realtime-аналитику или AI-функции, нуждаются в инфраструктуре данных с современным developer experience (DX). MooseStack от 514 — open-source DX-слой для ClickHouse.

---

Слияние дисциплин

Классические хранилища и озёра строились для аналитиков: SQL, BI-дашборды. Теперь же realtime-данные встроены в продукты и AI-функции, а команды разработки обязаны поставлять их так же быстро, как и обычный код.

• Транзакционные БД (Postgres, MySQL) хороши для разработки, но проваливаются при аналитических нагрузках.
• Облачные аналитические платформы (Snowflake, BigQuery) удобны для пакетных ETL, но не обеспечивают свежесть данных и sub-second ответов, а DX в них устарел.

---

UX-разрыв

Пользователи хотят аналитику за миллисекунды. ClickHouse решает задачу: на порядки быстрее Postgres и дешевле Snowflake/Databricks.

---

DX-разрыв

Разработчики привыкли к локальному циклу «код → тест → CI/CD». В мире данных такого нет: нет локального окружения, медленные итерации, конфликты между data- и software-инженерами.

---

MooseStack

514 выпустили MooseStack — open-source DX-слой поверх ClickHouse:

• Git-native, local-first, everything-as-code.
• Единый язык схем и запросов для всех специалистов.
• Поддержка CI/CD, preview-окружений, автотестов.

• Сторонники «чистого» инженерного подхода считают, что data engineering изначально был частью software engineering, но позже к нему примешались аналитики, знающие лишь SQL/DBT.
• В сообществе виден раскол: одни DE пишут Terraform, CI/CD, Spark и k8s, другие ограничиваются ноутбуками, SQL-запросами и no-code-инструментами.
• Критика Python и SQL как «недостаточно инженерных» языков: динамическая типизация, отсутствие строгих схем и нормального тестирования.
• Название роли «Data Engineer» стало размытым: HR ищут «писателей SQL», а специалисты просят называть их «Software Engineer, Big Data» или «Platform Engineer».
• Сильные практики уже давно используют IaC, версионирование, code review и полноценный SDLC, но таких меньшинство.

Почему мы отказались от WatermelonDB

• IndexedDB тормозит: WatermelonDB держит всю БД в памяти через LokiJS, что при 100 МБ+ данных недопустимо.
• Синхронизация хрупкая: клиент обязан сначала вытянуть данные, иначе мутации могут затереться.
• Проект замедлился: PR с чанковой загрузкой висит месяцами, активность упала.
• Web-ограничения: IndexedDB единственное постоянное хранилище в браузере, и все реализации страдают от его скорости.

Что мы искали

• Полноценная работа офлайн: чтение, удаление, ответ, сортировка писем без сети.
• Сотни МБ и миллионы строк с первого запуска — задача из топ-1 %.
• Кроссплатформенность: web + натив, общий знаменатель — браузер.
• Отказались от идеи «база-независимый API»: готовы интегрироваться на уровне Postgres, если это даст надёжность.

Первые кандидаты

Библиотека	Плюсы	Минусы
WatermelonDB	Open-source, проверен временем	Память, тормоза, слабая поддержка
PowerSync	Есть self-host	Требует кластер MongoDB + изменения Postgres, кейсы только демо
ElectricSQL	Переписывают, односторонняя синхронизация, требует Postgres

Итог
Альфа-версия на WatermelonDB работала, но к ноябрю стало ясно: для «тяжёлого» офлайна нужно что-то совсем другое. Мы начали поиск «новой волны» решений, отбросив все предубеждения.

• Автор поста (isaachinman) доволен Replicache+Orama, ждёт стабильности Zero, считает InstantDB созревшей, а Triplit теперь просто open-source.
• Критика: почти все решения (WatermelonDB, ElectricSQL, InstantDB, Convex) всё равно сидят на IndexedDB, который сам по себе «хак» и в Chrome построен на SQLite.
• Появляется надежда на Origin Private File System (OPFS) и WASM-SQLite, но пока боятся коррупций и нестабильности.
• Разработчики жалуются: мало примеров разрешения семантических конфликтов, ограниченные типы SQLite, сложности больших данных (ГБ+) и неясность, где open-source, а где нет.

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-решения.

Cactoide — мобильная open-source платформа для RSVP и управления мероприятиями.
Альтернатива Meetup.com и Eventbrite для малого бизнеса и небольших групп.

• GitHub: polaroi8d/cactoide
• Лицензия: MIT
• Стек: Go, PostgreSQL, React Native (iOS/Android), Tailwind CSS
• Функции
  • Создание/редактирование событий
  • Подтверждение участия (RSVP)
  • Push-уведомления
  • QR-коды на входе
  • Ограничение по билетам
  • Экспорт списков в CSV
• Установка

  git clone https://github.com/polaroi8d/cactoide.git
  cd cactoide
  docker-compose up
  

• Вклад: присылайте PR и issues.

• Meetup.com критикуют за цену ($180/год) и старый UI, но хвалят за базу участников и дискавери.
• Facebook/WhatsApp/Telegram используют бесплатно, но с плохим поиском и рассылками.
• Punchbowl, Luma, Partiful — удобные, но закрытые и собирают данные.
• Появляются открытые альтернативы: Mobilizon (федеративный), Cactoide (self-host, open-source, без регистрации).
• Основной барьер для новых платформ — отсутствие накопленной базы участников, а не функционал.

Мы перенесли Docker-реестр в собственный дата-центр на Harbor, отказавшись от Docker Hub и ECR.
Причины: счета за лицензию и трафик, 45-секундные задержки деплоя, риски утечек, лимиты API.

Критерии нового решения: надёжность, скорость, простота, open-source.
Выбрали Harbor: богаче функций, чем «голый» distribution, ставится через docker-compose.

v1-дизайн

• Хранилище: S3-совместимый Pure FlashBlade.
• Две независимые копии в Ashburn и Chicago (пока без HA PostgreSQL/Redis).
• Политики очистки для экономии места.

Минимальные права на бакет
s3:AbortMultipartUpload, DeleteObject, GetBucketLocation, GetObject, ListBucket, ListBucketMultipartUploads, ListMultipartUploadParts, PutObject

harbor.yml (фрагмент)

hostname: "#{node['fqdn']}"
http: { port: 80 }
data_volume: /data
storage_service:
  s3:
    bucket: docker-registry-bucket
    accesskey: "#{bucket_credentials['access_key']}"
    secretkey: "#{bucket_credentials['secret_key']}"
    regionendpoint: "https://purestorage.#{node['domain']}"
metric: { enabled: true, port: 9090, path: /metrics }

Конфиг разворачивается Chef на выделенных нодах, SSL-терминация на F5.

• Harbor удобен: SSO, Terraform-провайдер, но нет API для токена при docker login, приходится создавать robot-аккаунты.
• Ресурсы 32 CPU / 64 GB RAM выглядят завышенными для 32 000 пуллов за два месяца; скорее всего, просто оверпровижн.
• Многие используют один «источник истины» Harbor + региональные кэши или просто registry в режиме pull-through-cache.
• У Harbor нет OIDC-доступа из GitHub Actions, апгрейды ручные; Nexus проще для Maven/NuGet, но тоже прожорлив и иногда не чистит блобы.
• ECR в AWS дешёв (~3 $/мес) и без хостинга, но не on-prem; для S3-подобного хранилища советуют SeaweedFS, Garage или Pure Flashblade.

GNU Artanis — первый production-ready веб-фреймворк на Scheme. Лёгкий, быстрый, с поддержкой JSON/XML/SXML, WebSocket, i18n, MySQL/SQLite/PostgreSQL, кэширования, шаблонов и статики.

(use-modules (artanis artanis))
(init-server)
(get "/hello" (λ () "hello world"))
(run #:port 8080)

Скачать

• GNU FTP
• GitLab

Документация
Официальное руководство

Исходники

• Savannah: https://savannah.gnu.org/projects/artanis
• GitLab: https://gitlab.com/hardenedlinux/artanis

История
2013 — рождение на hack-potluck Guile; 2014 — награда «Lisp In Summer Projects»; 2015 — первая стабильная версия и вступление в GNU; 2021 — переход под крыло HardenedLinux.

Контакты
Почта: artanis@gnu.org
GitLab: https://gitlab.com/hardenedlinux/artanis

• Участники обсуждают фреймворк Artanis для Guile Scheme: кто-то хвалит простоту синтаксиса и встроенный веб-сервер, кто-то жалуется на отсутствие CSRF, 404-ссылок и слабое tooling.
• Почему Guile не стал популярен? Недостаток LSP, отладки, туториалов и узкая аудитория.
• Название «Artanis» — отсылка к Sinatra (Ruby) и палиндрому «Sinatra» задом-наперёд.
• Сайт без JS и шрифтов выглядит чисто, но кто-то считает текст слишком крупным и структуру странной.
• По безопасности: при грамотных разработчиках Scheme-системы могут быть безопаснее «обычных».

Материализованные представления очевидно полезны

Разработчики постоянно перетасовывают данные между системами и форматами.
Возьмём таск-трекер: нужно показывать количество задач в каждом проекте. Сначала всё просто:

const getTaskCountForProject = (id) =>
  db.query('select count(1) from tasks where project_id = $1', [id]);

Скорость не устраивает → добавляем Redis-кеш:

const getTaskCountForProject = async (id) => {
  const key = `project:${id}:task-count`;
  let cnt = await redis.get(key);
  if (cnt !== null) return +cnt;
  cnt = await db.query('select count(1) ...', [id]);
  await redis.set(key, cnt, { ex: 3600 });
  return cnt;
};

Пользователи жалуются: счётчик устаревает. Приходится чистить кеш при каждом insert/delete.
Делаем инкрементальные обновления:

await redis.incr(`project:${id}:task-count`);

Но если сервер упадёт между записью в БД и Redis, счётчик сломается навсегда.
Переносим счётчик в ту же БД и обновляем в транзакции, либо пишем триггер — логика в БД снова в моде.

Итог: из одной строки кода выросла куча кода, который нужно поддерживать и синхронизировать.
Таких «побочных» вычислений в приложениях тысячи; они скрывают суть и мешают рефакторингу.

• Пост хвалят за честность, но автор не уточняет СУБД, хотя SQL выглядит как Postgres.
• Postgres-материализованные представления требуют ручного REFRESH; авто-обновления дают коммерческие продукты (Materialize, Snowflake, MSSQL, ReadySet, Feldera, RisingWave) и расширение pg_ivm.
• Convex, Zero и др. используют инкрементное обслуживание представлений (IVM) «под капотом».
• Счётчики через COUNT(*) без IVM не масштабируются; кто-то предлагает денормализацию и триггеры, кто-то — индексы по FK.
• ScyllaDB-материализованные представления считаются багованными; важно понимать конкретную реализацию.

ChartDB — инструмент для интерактивной визуализации схем БД.
Поддерживает PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, CockroachDB, MongoDB.

Ключевые возможности

• Импорт схемы одним кликом из любой поддерживаемой СУБД.
• Авто-раскладка таблиц и связей; ручное перемещение.
• Экспорт в форматы PNG, SVG, PDF.
• Режим «одной страницы» для быстрого просмотра.
• Поиск и фильтрация по названию таблицы или столбца.
• Тёмная и светлая темы.

Быстрый старт

1. Открыть chartdb.io.
2. Нажать «Import from DB», вставить строку подключения или SQL-дамп.
3. Получить готовую схему за секунды.

• Некоторые команды продолжают рисовать ERD и документировать именно схему БД, особенно при проектировании новых фич и онбординге.
• Другие полагаются на абстракции вроде ORM/DDD и считают диаграммы избыточными, особенно для типовых SaaS с generic auth и payment.
• Инструменты вроде dbdiagram.io, Lucidchart и ChartDB спросом пользуются, но часто ломаются при >15 таблиц или требуют изучения нового UI.
• Сторонники диаграмм аргументируют: «базы живут дольше абстракций», а отсутствие документации — потеря для индустрии.

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-приложений.
• Главный вывод: анализаторы кода должны запускаться в изолированных средах без доступа к чувствительным переменным, иначе подобные инциденты неизбежны.

Проблема
При промахе кэша Readyset выполняет запрос с нуля. Для «расколотых» соединений (предикаты есть и в WHERE, и в ON) старый hash-join читал обе таблицы полностью:

• фильтр по email возвращал 1 строку users;
• фильтр по status='SHIPPED' — 99 % таблицы orders.
  Материализовав миллионы лишних строк, система строила хэш-таблицу и лишь потом отбрасывала ненужное. Профилирование показало: 30 % времени уходило на распаковку RocksDB, затем на 10 K IOPS и 81 % загрузки NVMe.

Решение: Index Condition Pushdown
Новый план использует индексы и «проталкивает» условия вниз:

1. Сначала выбираем 1 строку users по индексу email.
2. Для каждой найденной u.id делаем индексный lookup в orders с условием user_id = u.id AND status='SHIPPED'.
   Так читаются только нужные строки orders, объём I/O падает на порядки, а хэш-таблица больше не строится.

Результат
ICP устраняет лишнее чтение и распаковку, превращая холодный straddled-join из многомиллисекундной операции в субмиллисекундную.

• Пользователи жалуются, что планировщик запросов не продавливает фильтры к индексам, и считают это багом производительности.
• Многие разработчики вынуждены сами заниматься индексами, партиционированием и анализом EXPLAIN, потому что DBA лишь «держат свет».
• В RonDB и ReadySet показали примеры «pushdown-joins» и Index Condition Pushdown, дав ускорение до 450×.
• ReadySet описывают как «кеш-прокси» поверх MySQL/Postgres, который по логу репликации инкрементально обновляет материализованные представления.
• Часть участников считает, что современные оптимизаторы должны делать такие оптимизации автоматически, и не понимает, зачем изобретать велосипед.

ClickHouse vs PostgreSQL: UPDATE-скорость

• Коротко: на одном железе ClickHouse догоняет PostgreSQL в одиночных UPDATE и в 4 000 раз быстрее при массовых.
• Почему: колоночное хранилище + параллелизм ClickHouse выигрывает у строкового PostgreSQL при поиске и перезаписи миллионов строк.
• Но: PostgreSQL всегда транзакционен; ClickHouse — нет, поэтому сравнение по «родным» режимам, а не по ACID.

Что мерили

• 1 строка: UPDATE orders SET status='shipped' WHERE id=1234567
• 1 млн строк: UPDATE orders SET discount=0.1 WHERE order_date<'2023-01-01'

Аппаратура

• c6i.8xlarge (32 vCPU, 64 ГБ RAM, gp3 SSD)
• PostgreSQL 16.4 (дефолт + fillfactor=90, checkpoint_timeout=30 min)
• ClickHouse 25.7 (дефолт)

Результаты

метрика	PostgreSQL	ClickHouse
1 строка, мс	0.12	0.11
1 млн строк, сек	120	0.03
CPU, %	100	2800
чтение, ГБ	30	0.8

Почему так

• Поиск: ClickHouse читает только нужные колонки, фильтрует за счёт индексов и распараллеливает на все ядра.
• Запись: обе СУБД пишут новые версии строк (MVCC), но PostgreSQL переписывает целые страницы, а ClickHouse — только изменённые куски колонок.
• Фоновая работа: PostgreSQL ждёт checkpoint’а, ClickHouse сразу сортирует и сжимает куски.

Когда выбирать

• Нужны транзакции и row-level locks → PostgreSQL.
• Нужны массовые обновления аналитических данных → ClickHouse.

Код и данные

GitHub

• ClickHouse показывает огромный выигрыш в скорости обновлений, но это «яблоки-к-апельсинам»: PostgreSQL по умолчанию полностью транзакционен, а CH — нет.
• Если данные можно терять или обновления редки, CH идеален; если нужна строгая согласованность, PostgreSQL остаётся безальтернативным.
• Многие пользователи CH считают обновления адом: приходится использовать ReplacingMergeTree, версии или event-sourcing; прямых UPDATE-ов до недавнего времени вообще не было.
• Часть комментаторов предлагает сравнивать CH с DuckDB, Vertica или ScyllaDB, а также настроить PostgreSQL (synchronous_commit = off, COPY) для более честного бенчмарка.
• Авторы поста подчёркивают: цель не «победить» PostgreSQL, а показать, как каждая СУБД решает задачу в своей «родной» модели исполнения.

Итоги постройки синхронизатора и реактивной системы на SQLite

Первый опыт: PGlite + Electric

• PostgreSQL в WASM + Electric даёт точную синхронизацию и LISTEN-реактивность.
• Недостатки: Electric ещё молод, старт до минуты без компакции; PGlite в single-user-режиме течёт памятью и тормозит при росте БД.

Переосмысление задачи

• SQLite-WASM стал зрелым; моё приложение однопользовательское и почти всегда онлайн.
• Значит, достаточно простого собственного решения.

Минимальный синхронизатор

1. При первом запуске клиент вытягивает всё по updated_at.
2. Каждые 2–3 с опрашивает сервер за записями новее этой метки и делает upsert.
3. Локально при каждом UPDATE ставится флаг modified = 1; фоновый процесс отправляет изменения.
4. Для текстов можно добавить CRDT (Yjs) на случай конфликтов.
   Для отслеживания изменений используется триггер, который игнорируется во время синхронизации через таблицу sync_control.

Реактивность на SQLite

• SQLite не умеет LISTEN, но:
  1. Триггер пишет в лог-таблицу пару «таблица + id».
  2. Broadcast Channel API рассылает это в другие вкладки/воркеры.
  3. UI подписывается на канал и перечитывает нужные строки.
• Использую wa-sqlite: стабильно, без сбоев с момента установки.

• Сообщество обсуждает проблемы PGlite и Electric, поэтому Electric развивает Tanstack DB как «sync-native» JS-решение без привязки к бэкенду.
• Предлагаются альтернативы: Evolu, SQLite-Sync, CouchDB и CRDT-движки, но авторы предупреждают, что продакшен-синхронизация сложнее PoC.
• Некоторые отказались от SQLite в браузере вовсе, храня лишь простые индексы и рассылая дельты.
• Участники подчёркивают важность консенсуса (Lamport/CRDT/raft) и отмечают, что гранулярная синхронизация не гарантирует консистентность без транзакций или разрешения конфликтов.
• В итоге рекомендуют использовать готовые движки, а не изобретать велосипед, особенно если нужны офлайн, e2e-шифрование и многопользовательский доступ.

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», другие подчеркнули пользу такого «терапевтического» лога ошибок.