Hacker News Digest

PlanetScale анонсировал запуск однодневного режима своей базы данных по цене $5 в месяц. Новая конфигурация PS-5 предназначена для разработки, тестирования и некритичных рабочих нагрузок, предлагая вертикальное масштабирование без добавления реплик. Это значительно дешевле предыдущего минимального тарифа в $30 за 3-узловой кластер с высокой доступностью. Компания отмечает, что ежедневно получает запросы на более доступный тариф для разработчиков на начальном этапе.

Новая структура ценообразования включает различные типы узлов (PS-5, PS-10) как в однодневном, так и в HA-режиме. Клиенты могут начать с малого и масштабироваться до гипермасштабирования без смены платформы базы данных или сложной миграции. Запуск новой функции запланирован на ближайшие пару месяцев, а желающие могут зарегистрироваться для получения уведомлений о доступности.

• Пользователи вспоминают, как PlanetScale отменил бесплатный тариф, что стало причиной увольнения сотрудников и изменения дизайна сайта.
• Некоторые участники обсуждения считают, что отсутствие бесплатного уровня делает невозможным тестирование сервиса, в то время как другие подчеркивают, что бесплатные продукты неустойчивы и могут быть отменены в любой момент.
• Обсуждается, что цена в 5 долларов за базу данных может быть недостаточной для покрытия затрат на обеспечение высокой доступности и репликации, что вызывает вопросы о долгосрочной жизнеспособности таких планов.
• Некоторые участники обсуждения высказывают мнение, что отсутствие бесплатного уровня может отпугнуть новых пользователей, в то время как другие считают, что это может быть выгодно для компании в долгосрочной перспективе.

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

ImapGoose — это инструмент для синхронизации почты, работающий в режиме реального времени. В отличие от традиционных решений, которые выполняют синхронизацию периодически, ImapGoose работает как демон, отслеживая изменения как на сервере (через IMAP), так и в локальной файловой системе (через inotify/kqueue). Это позволяет моментально отражать изменения: новое письмо на сервере появляется в файловой системе в течение секунды, а удалённое в другом клиенте — исчезает локально.

Ключевые особенности включают поддержку современных расширений IMAP, таких как CONDSTORE (2006) для эффективного определения изменений, QRESYNC (2008) для работы с удалениями и NOTIFY (2009) для мгновенных уведомлений об изменениях. Это позволяет ImapGoose минимизировать трафик и избегать массовой пересинхронизации.

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

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

• Пользователи обсуждают, какие инструменты (mbsync/isync, imapfilter, isync/notmuch, mu4e, aerc, gnus) лучше всего использовать для синхронизации и чтения почты в условиях нестабильного интернета и отсутствия push-уведомлений.
• Поднимается вопрос, насколько современные почтовые клиенты (Thunderbird, Apple Mail, Outlook) используют такие же стратегии и расширения.
• Участники обсуждают, что происходит при потере соединения и как обеспечивается надежная синхронизация состояния почты.

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.

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

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

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

Министерство внутренней безопасности США годами собирает ДНК граждан, включая несовершеннолетних от 14 лет, и передаёт их в базу данных ФБР CODIS, предназначенную для расследования преступлений. С 2020 по 2024 год было собрано почти 2000 образцов от американцев, 95 из которых — дети, причём многие не были обвинены в каких-либо преступлениях. Это происходит без санкции Конгресса и нарушает федеральный закон, разрешающий сбор ДНК только при уголовных арестах.

Программа резко расширилась с 2020 года из-за изменения правил Министерства юстиции, и теперь в CODIS попадают образцы от задержанных по гражданским делам, включая мигрантов и путешественников. К апрелю 2025 года база содержала уже 2,6 млн профилей, 97% из которых собраны по гражданским основаниям. Эксперты предупреждают, что попавшие в базу могут пожизненно подвергаться повышенному вниманию правоохранительных органов.

• Обсуждение касается сбора и использования ДНК государством, проводя параллели с массовой слежкой и отмечая, что эта практика часто имеет широкую политическую поддержку.
• Участники отмечают, что люди часто добровольно и даже платно предоставляют свои данные (например, через коммерческие сервисы ДНК), что создаёт обширные базы для правительства.
• Приводятся конкретные примеры из Калифорнии, где хранится ДНК каждого новорождённого, и кейсы, как такая база помогает раскрывать преступления через поиск родственников.
• Многие пользователи иронично замечают, что теории заговора, которые раньше высмеивались (как в «Секретных материалах»), теперь оказываются правдой.
• Один из комментаторов делится личным опытом, как ДНК его родственницы-генеалога помогла поймать преступника, иллюстрируя практическую пользу таких баз.

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

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

Многие считают разработку ПО скучной работой, где нужно просто писать то, что просят менеджер или клиент. Сначала это увлекательно, но через несколько итераций становится рутиной.

Всё, что не вызывает у тебя интереса, нужно менять.

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

• CI/CD работает слишком долго из-за отсутствия кэширования.
• Отсутствие пула соединений приводит к перегрузке базы данных.
• Неправильная настройка сборщика мусора вызывает утечку памяти.
• Если код, написанный неделю назад, непонятен через 3 секунды — он плохо написан.
• Высокая задержка для пользователей из-за удалённости серверов.
• Замедление базы данных при пакетной вставке данных.
• Несогласованность ответов API для пользователей в разных регионах.

Это нетривиальные проблемы, они возникают каждый день. Это наши «злодеи» — раздражающие, нежеланные и неожиданные. Мы должны их устранять.

Выбирайте свои «битвы». Это способ сделать день интереснее. Если на работе такие задачи недоступны, решайте их в личных проектах.

Если вы преследуете правильное напряжение, за ним последует история.

• Участники дискуссии в основном не согласны с идеей о том, что скучной работе нужна напряженность (tension). Вместо этого предлагается искать в такой работе смысл (meaning) или дисциплину. • Многие считают погоню за напряженностью вредной, сравнивая ее с дофаминовой петлей, которая не приводит к значимым результатам. • Несколько комментаторов отмечают, что рутинная, последовательная работа часто является основой для по-настоящему великих достижений. • Другие предлагают автоматизировать скучные задачи, чтобы высвободить время для более ценной и rewarding деятельности. • Часть обсуждения свелась к тому, что разные люди мотивированы по-разному, и что невозможно обобщить один опыт на всех.

• 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, что отпугивает многих.

SQLite и надёжность: бардак в настройках

Надёжность (durability) — гарантия, что после COMMIT изменения сохранятся даже при падении ОС или отключении питания. На Linux это обеспечивается вызовом fsync. Цена — производительность, поэтому СУБД дают «ручки» для настройки. Главное, чтобы документация чётко объясняла, что включено по умолчанию.

У SQLite всё запутано. Два ключевых параметра:

• journal_mode (DELETE | WAL …)
• synchronous (EXTRA, FULL, NORMAL, OFF)

По документации:

• По умолчанию journal_mode=DELETE, synchronous=FULL.
• В режиме DELETE FULL не гарантирует надёжность; нужен EXTRA.
• В режиме WAL FULL уже достаточно.

Вывод: «из коробки» SQLite не надёжна; переключившись на WAL — становится.

Однако Ричард Хипп (автор SQLite) в комментарии на HN утверждает прямо противоположное:

• «В конфигурации по умолчанию SQLite надёжна».
• «Если включить WAL, по умолчанию надёжность теряется».

Документация и автор расходятся.

Дополнительные ловушки:

• Обертки могут переопределять synchronous. Популярный драйвер Go для SQLite ставит NORMAL в WAL-режиме — надёжности нет.
• На macOS fsync работает не как на Linux, что тоже снижает гарантии.

Итого: чтобы быть уверенным, явно задайте
PRAGMA journal_mode = WAL; PRAGMA synchronous = FULL;

• Участники спорят, что «durability» в SQLite зависит от комбинации journal_mode и synchronous, а не от единого определения.
• По-умолчанию (DELETE + FULL) SQLite не гарантирует durability при сбое ОС/питания, потому что fsync не всегда успевает закрепить журнал.
• WAL по умолчанию защищает от краха приложения, но не от краха ОС; для полной durability нужно synchronous=FULL.
• Некоторые считают документацию ясной, другие — запутанной и просят примеров выбора режимов.
• Поднимаются вопросы надёжности fsync, файловых систем и дисков, а также желание «SQLite 4» с новыми умолчаниями.

Base — компактный и мощный редактор SQLite для macOS.

Скачать бесплатно | Купить

Возможности

• Инспектор схем
  Быстро просматривайте структуру таблиц, типы столбцов и связи без SQL.

• Визуальный редактор таблиц
  Создавайте и изменяйте таблицы мышью, без CREATE/ALTER.

• Браузер данных
  Просматривайте, фильтруйте и правьте записи прямо в таблице.

• SQL-редактор
  Пишите запросы с подсветкой синтаксиса, автодополнением и сохранением сниппетов.

• Импорт/Экспорт
  Загружайте CSV и SQL-дампы; выгружайте в CSV, SQL, JSON и Excel.

Системные требования

macOS 15 Sequoia и выше.
Бесплатная версия ограничена; полная — единоразовая покупка.

Документация | Контакты

• Пользователи удивлены, что Base существует уже 15 лет, но плохо заметен в поиске.
• Хвалят «ремесленный» подход: маленькая команда, узкая задача, высокое качество.
• Часто сравнивают с TablePlus, Postico и sqlitebrowser, отмечая превосходство в «родном» macOS-UX.
• Просят добавить DuckDB, UUID, автозагрузку расширений, FK по умолчанию и диаграммы схемы.
• Покупатели благодарны за возможность покупки вне Mac App Store и за льготную цену.

SQLite в режиме WAL по умолчанию не вызывает fsync после каждого COMMIT.

• Параметр PRAGMA synchronous=NORMAL (значение по умолчанию) не гарантирует сохранность транзакции при внезапном отключении питания.
• В этом режиме fsync выполняется лишь:
  – перед контрольной точкой WAL;
  – после завершения контрольной точки;
  – при повторном использовании WAL-файла.
• Для жёсткой гарантии сохранности нужно:

  PRAGMA synchronous = FULL;
  

  Тогда после каждого COMMIT будет вызываться fsync WAL-файла.

• По умолчанию SQLite компилируется с synchronous=FULL, но дистрибутивы или обёртки могут изменить это.
• Не стоит полагаться на умолчания — явно задавайте параметры, особенно если нужна надёжность.
• WAL-режим ускоряет работу, но требует общей памяти и нарушает ACID для attached БД.
• На macOS для гарантированной надёжности нужен F_FULLFSYNC, но Apple использует собственную реализацию.
• Litestream рекомендует synchronous=NORMAL, так как и так делает регулярные бэкапы.

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.
• Сторонники диаграмм аргументируют: «базы живут дольше абстракций», а отсутствие документации — потеря для индустрии.

• Security: киберпреступность, патчи, исследования, CSO
• Off-Prem: edge + IoT, канал, PaaS/IaaS, SaaS
• On-Prem: системы, хранение, сети, HPC, персональные технологии, CxO, госсектор
• Software: ИИ + ML, приложения, БД, DevOps, ОС, виртуализация
• Offbeat: дебаты, колонки, наука, юмор, юр. новости, блоги
• Спецпроекты: месяц облачной инфраструктуры, сети ЦОД, хранение, европейские суперкомпьютеры, ИИ-инфраструктура, RSAC, разработка ИИ, аварийное восстановление, GTC Nvidia, ransomware, будущее ЦОД, кибербезопасность, VMware Explore
• Vendor Voice: Siemens + AWS, Mendix + AWS, финансовые потоки, BigQuery, AWS Global Partner Security, GE Vernova
• Ресурсы: whitepapers, вебинары, рассылки

• Все, что вы отправляете в онлайн-сервисы (AI, почта, соцсети), сохраняется навсегда и может быть использовано против вас.
• Большинству пользователей всё равно: удобство «бесплатных» сервисов перевешивает риски.
• Есть альтернатива — локальные модели (Ollama, LM Studio, Oobabooga), но они требуют мощного железа и навыков.
• Даже если вы не пользуетесь сервисом, друзья могут передать ваши данные через чат-ботов.
• Пока не появится жёсткое регулирование, единственный надёжный способ — не делиться чувствительной информацией и минимизировать использование облачных AI.

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, а показать, как каждая СУБД решает задачу в своей «родной» модели исполнения.