Hacker News Digest

Злоумышленники заявили о краже 10,6 ТБ данных из облачной платформы TiDB Cloud компании PingCAP — это 4 901 203 файла, включая полный контрольный слой продакшена. По их словам, выгрузка шла почти два месяца и оставалась незамеченной: 88 последовательных экспортов каждые шесть часов с 8 по 30 сентября, последний — в 06:02 UTC 30 сентября. Репликацию собственной базы данных TiDB Cloud они настроили через учётные данные, найденные в репозиториях самой компании: ключи сервисного аккаунта GCP и субъект Azure.

Среди похищенного — 180 046 организаций-арендаторов, 292 276 записей пользователей, 403 262 уникальных адреса электронной почты, 115 308 пар ключей API в открытом виде (42 612 активных), 20 645 574 SQL-запроса клиентов из редактора и Chat2Query, 102 003 766 подключений к шлюзу, 5 036 738 IP-адресов серверов заказчиков, 377 446 задач Jira, 433 928 контактов CRM, 92 ГБ данных о затратах AWS с метками арендаторов и 413 приватных репозиториев с исходным кодом. Также упоминаются 1 809 внешних конечных точек баз данных с учётными записями root и admin на хостах MySQL/Aurora заказчиков и 290 идентификаторов аккаунтов AWS.

Первый этап публикации — около 200 ГБ, доступен через торрент-файл размером 128,3 ГиБ. Атакующие подчёркивают, что PingCAP, будучи облачным провайдером, не заметил массовой выгрузки из AWS, GCP, Jira и Azure, хотя компания зарабатывает на обещании безопасности мультитенантной платформы.

Обсуждение указывает на катастрофический уровень операционной безопасности PingCAP: инженеры хранили production-учетные данные клиентов и ключи сервисных аккаунтов GCP и Azure в тикетах Jira и репозиториях. Это позволило атакующим настроить автоматическую репликацию данных в течение месяца. Сообщество ставит под сомнение заявления компании об отсутствии воздействия на данные, так как у хакеров есть полные дампы контрольного слоя. В споре о природе утечки @gregwebs считает, что утекли в основном метаданные, однако другие указывают на наличие SQL-логов с реальными данными клиентов. Проведенный ранее аудит NCC Group выявил разрыв между анализом кода и реальной безопасностью процессов. @kobieps отмечает необходимость перестройки индустрии пентестов, так как даже enterprise-grade вендоры допускают подобные провалы. @ozgrakkurt полагает, что безопасность была бы выше при использовании консервативной модели разрешений (как в Deno), где всё закрыто по умолчанию. Также пользователи иронизировали по поводу Rust, но @boorbat уточнил, что TiDB на 95% написан на Go.

Вышел DuckDB 2.0.0 с длительной поддержкой (LTS), кодовое имя «Cinnamon Teal» — в честь коричной чирки, красновато-бурой утки из западных Америк. Это крупнейший по числу функций релиз: почти 20 000 коммитов с версии 1.5. В отличие от 1.0, делавшей ставку на стабильность и обратную совместимость, 2.0 — прежде всего функциональный выпуск. В него вошли отточенная версия протокола Quack, асинхронный ввод-вывод, полноценный тип VARIANT, режим агента, триггеры и расширяемый парсер SQL.

DuckDB изначально была встраиваемой базой, но теперь её можно запускать в классической схеме «клиент — сервер»: расширение quack реализует родной протокол, а новый оператор CONNECT позволяет подключать удалённую базу и переключаться на неё одной командой. Поддержка 2.0 продлится как минимум до октября 2027 года; предыдущая LTS 1.4 поддерживается до конца ноября 2026-го, а срок поддержки 1.5 продлили до марта 2027-го, фактически тоже сделав её LTS. Сборка «amalgamation» (весь исходный код в одном заголовочном и одном исходном файле) объявлена устаревшей, а платформа osx_amd64 постепенно выводится из числа полностью поддерживаемых — в 2.1 её поддержка прекратится.

Обсуждение дополняет статью кейсами использования DuckDB как замены Spark, инструмента для анализа логов, федеративного движка для объединения разрозненных источников (включая таблицы) и основы для браузерных приложений. Основные тезисы: — Версия 2.0 значительно ускорила работу на многоядерных системах (EC2): @RobinL отмечает утилизацию до 128–192 vCPU (против 64 ранее), что позволило обработать 1 млрд записей за 10 минут. — Для сжатия логов @jiggawatts за два часа перевел 7 ТБ NDJSON из Azure в Parquet, сократив объем до 2,5%. — Асинхронный I/O при работе с удаленными данными (S3/HTTP) и паттернами glob (например, `*.parquet`) предотвращает блокировку рабочих потоков (@jtbaker, @skeeter2020). — DuckDB позволяет обходить проблемы row-based security в централизованных хранилищах, предоставляя пользователям локальные копии данных (@skeeter2020). — С помощью duckdb-wasm и оптимизации раскладки данных в браузер можно передавать от 2–3 млн строк (16–20 МБ) до 1 ГБ через HTTP range queries (@gopalv). — Клиент-серверная архитектура позволяет создавать легковесные сервисы с горизонтальным масштабированием или масштабированием до нуля через Cloud Run (@paoliniluis, @jtbaker, @bambax). — Для интеграции с инструментами анализа (например, Metabase) рекомендуются расширения Quack или поддержка Postgres wire (@nicoritschel, @paoliniluis). — При использовании в качестве основного сервера БД с транзакциями рекомендуется ограничиться одним записью (single writer) (@netcraft, @throwawaythekey).

DHH переписал Campfire Once с Ruby on Rails на Rust, Elixir и Go, используя ИИ-агента («clanker»), не читая и не пишя код сам. Результаты показали, что без чётких промптов и понимания требований ИИ принимает произвольные решения: например, Rust-версия отказалась от CSRF-токена и Redis ради упрощения кэширования, тогда как Elixir-версия сохранила близость к оригиналу. Эти различия не зависят от языка — они отражают неявные trade-offs, которые ИИ выбирает сам, когда не указаны приоритеты по совместимости, latency, throughput или использованию памяти.

Кроме того, в коде проявились серьёзные технические ошибки: в Elixir-версии SQL-запросы обрабатываются последовательно, даже если они могли бы выполняться параллельно; в Rust-версии некоторые БД-операции блокируют async-задачи, а синхронные мьютексы удерживаются слишком долго, блокируя весь worker-поток из-за кооперативной планировки Tokio. Увеличение буфера broadcast с 256 до 16384 улучшило доставку при 100 req/s с 14% до 90%, но привело к росту pMAX latency с 11с до >130с — что хуже, чем быстрый сброс и reconnect. При нагрузке Elixir-версия потребила 1.8ГБ памяти, ставя вопрос: лучше ли потерять сообщения или рискнуть OOM-kill? Вывод: никакой язык или ИИ не заменяют критического мышления — нужно понимать failure modes, устанавливать осознанные лимиты и не верить в «магические» решения. Benchmarks сложны, а надежность требует знания того, когда и как отказывать.

Из обсуждения

• @variety8675: This article just reminds me that workslop is so hard to counter because it takes no effort to produce and immense effort to debunk
• @discreteevent: It's worth noting that the context here is a system that was translated by an LLM which is the ideal use case for it. 90% of the thinking had already been done by developers of the existing system.

Polars 2.0 стал значительным шагом вперёд, объединяя улучшения производительности, поддержку SQL как первого класса и переход к потоковой обработке по умолчанию. Теперь вызов collect на LazyFrame использует потоковый движок, что снижает потребление памяти и ускоряет большинство запросов, хотя требует явного указания порядка строк для операций вроде join и group_by, чтобы избежать неожиданных результатов. Добавлен новый тип данных Map, а контроль над типами стал строже — это ускоряет обратную связь и упрощает работу с ИИ-моделями.

В тестах TPC-H и TPC-DS Polars 2.0 показал лучшие результаты среди DuckDB (1.5.6 и 2.0 alpha) и DataFusion на машинах с 16 и 192 ядрами, особенно при ограничении потоков до 32 ядер на больших системах, где изначально наблюдался накладный расход при масштабировании. На больших данных (SF100) Polars с 192 ядрами оказался в 3.8 раза быстрее на TPC-H и в 2.2 раза на TPC-DS по суммарному времени запросов, опережая DuckDB и DataFusion в масштабируемости. Исходные данные и скрипты для воспроизведения тестов доступны в открытом репозитории. Разработчики обещают улучшить масштабирование на большом числе ядер и продолжить работу над out-of-core и GeoPolars.

Polars 2.0 почти полностью заменяет Pandas для обработки больших данных, за исключением геопространственных задач (нет аналога Geopandas, Geopolars в разработке), тонких строковых операций и совместимости с экосистемой SciPy, где Pandas доминирует из-за ожидания DataFrame-объектов. При работе с миллиардами строк Polars работает за 5 секунд против 4 минут 28 секунд у Pandas, а DuckDB использует в 19 раз меньше памяти. Потоковая обработка по умолчанию в Polars 2.0 устраняет утечки памяти от неправильного использования collect() в циклах. Пользователи отмечают лучший API и производительность Polars в greenfield-проектах, его логика ближе их мышлению. Для сложных строковых операций (например, конкатенации с текстом между столбцами) Pandas проще: df['col_a'] + 'text' + df['col_b'], тогда как Polars требует более громоздкого кода. Для научных библиотек (SciPy) Pandas предпочтительнее, так как многие инструменты ожидают DataFrame. Для сложных JOIN и агрегации на очень больших наборах данных DuckDB может быть предпочтительнее Polars. Есть противоречия в бенчмарках: некоторые утверждают, что DataFusion быстрее Polars, другие — что DuckDB уступает Polars. Также отмечается неоднозначность в поддержке наносекундных временных меток в Polars — некоторые пользователи сталкиваются с проблемой экспорта, другие нет. SQL в Polars 2.0 улучшен, но не поддерживает все операции (например, asof_join), ограничивая применение в некоторых аналитических сценариях. Пользователи, обрабатывающие миллиарды метеоданных, подтверждают, что версия 2.0 жизненно важна для их workflows. Для тех, кто использует SQL, Malloy предлагает более читаемый синтаксис, заменяя 40+ строк Polars/Pandas одной декларативной инструкцией.

SQLDoom переносит оригинальный Doom 1993 года полностью в SQL: логика игры и рендерер реализованы как запросы к базе данных CedarDB. Игровой цикл работает с оригинальными 35 FPS, а рендерер генерирует полный буфер кадра 320×200 пикселей до 60 Гц на ноутбуке. Python используется только для обработки ввода, синхронизации таймингов и вывода полученного битмапа. Поддерживается мультиплеер — deathmatch на четырёх слотах, доступный через публичные серверы в ЕС и США. Для рендеринга используется BSP-дерево, как в оригинале, что позволяет корректно упорядочивать глубину, накладывать текстуры, обрабатывать наклонные стены и переменную высоту пола — в отличие от предыдущего проекта DOOMQL, основанного на упрощённом рейкастинге. Хотя SQLDoom медленнее нативного бинарника из-за множества уровней абстракции, разрыв оказался неожиданно мал благодаря оптимизатору CedarDB и JIT-компиляции в LLVM. Для запуска требуется CedarDB Community Edition, Python с psycopg2 и pygame, а также IWAD-файл Dooma (shareware-версия доступна через пакетный менеджер). Исходный код доступен на GitHub, а играть можно прямо сейчас via веб-интерфейс, где при заполненных слотах игрок помещается в очередь, но может продолжать исследовать игровое состояние через SQL-запросы. Проект демонстрирует, насколько далеко можно зайти, используя СУБД не только для хранения данных, но и как платформу для выполнения сложных вычислений в реальном времени. John Carmack называют гением за то, как он извлёк максимум из ограниченного железа 1993 года — подход, который теперь находит отклик даже в неожиданных средах вроде SQL.

SQL способен реализовать сложную игровую и бизнес‐логику: 5900 строк SQL заменяют ~9000 строк C, обеспечивая полноценный цикл рендеринга и физики. Хранение состояния в таблицах гарантирует атомарность и согласованность, устраняя потерю данных. Однако при большом числе игроков возникают проблемы с блокировками и масштабируемостью. Отладка хранимых процедур, отсутствие контроля версий и культурные барьеры делают такой подход спорным в реальных проектах. В полупроводниковом производстве процедуры использовались для ежедневного изменения правил сотнями пользователей на копии продакшн‐БД, но копировать продакшн‐БД ежедневно нереально для крупных систем из‐за объёма данных. Современные альтернативы (например, функции SpacetimeDB) и ограниченный набор стандартных функций в MSSQL снижают привлекательность чистого SQL для сложной логики. Рекомендуется держать меняющуюся и сложную бизнес‐логику в приложении, а в базе оставлять только ограничения и простые процедуры как резерв. Использование планировщика запросов как конечного автомата считается инженерным злоупотреблением, несмотря на сокращение кода. Выбор места логики часто определяется корпоративной культурой, а не только техническими факторами: многие избегают «болота» SQL‐логики. Существуют языки, компилирующиеся в SQL, которые можно использовать для реализации алгоритмов внутри БД. Проект уже развернут на EU и US серверах, подтверждая практическую возможность мультиплеерного режима в SQL‐базе. Опыт разработки многопользовательских игр с атомарными транзакциями показывает, что паттерн работает при правильном решении проблем конкурентного доступа (см. Designing Data‐Intensive Applications).

В 2026 году 16-летний исследователь безопасности Фаав обнаружил критическую уязвимость в внутреннем сервисе Microsoft Titan, позволявшую обойти аутентификацию. Сервис не проверял цифровую подпись JWT-токенов — достаточно было подделать поле upn на admin, чтобы получить права администратора и выполнять произвольные SQL-запросы к 17,3 триллионам строк данных без реальных учётных данных. Доступ к таблицам был получен лишь через метаданные из архивов Wayback Machine и тестовые примеры, без доступа к внутренней сети.

Фаав использовал собственный AI-бота Antares для автоматического поиска уязвимостей, но ключевой прорыв произошёл после ночной догадки: замена upn на admin сработала. Уязвимость была немедленно исправлена Microsoft, за что исследователь получил $5 000. Важнейший урок: даже сложные системы аутентификации бесполезны, если не проверяется подпись токена — это фундаментальная ошибка, которую легко допустить, но невозможно игнорировать.

Сообщество считает выплату в $5 000 за уязвимость, позволяющую выполнять произвольные SQL-запросы к 17 трлн строк, заниженной и не отражающей реальную стоимость эксплойта. В то время как @muglug полагает, что сумма оправдана вероятностью использования бага государственными акторами, @bix6 и другие требуют минимум $100 000. Программы вознаграждений Microsoft часто называют «патетичными» на фоне других компаний. Критическим уязвимым местом признан алгоритм JWT "none", который необходимо удалить из спецификаций и реализаций. Для защиты рекомендуется использовать и регулярно обновлять библиотеку Microsoft Identity Service Essentials (MISE). Низкие выплаты и эксплуататорский контроль Microsoft над текстом раскрытия (особенно в случае с несовершеннолетним автором) могут подтолкнуть исследователей к продаже данных на чёрный рынок или привести к юридическим конфликтам. Для исправления ситуации предлагается повышать вознаграждения за критические баги и ввести законодательные гарантии защиты исследователей, раскрывающих уязвимости без нанесения вреда.

Языковая модель с 4 миллиардами параметров была дообучена с помощью supervised fine-tuning и agentic reinforcement learning для генерации планов выполнения SQL-запросов в PostgreSQL, которые работают быстрее, чем планы, выбранные стандартным оптимизатором. На этапе SFT модель научилась генерировать корректные планы для 14 из 113 ранее неразрешимых запросов, а после RL — для всех 113. В результате среднее время выполнения запросов сократилось на 44,7% по сравнению с планами PostgreSQL, а в лучших случаях — до 81%. Для устранения шума измерений был создан специальный стенд с изолированными контейнерами и минимизацией влияния кэша страниц Linux. Для обучения в шумной среде разработана модификация алгоритма GRPO, а обучение распределено между арендованным узлом с двумя H100 (для vLLM и тренера) и локальными четырьмя контейнерами PostgreSQL. Кроме того, использовано off-policy дистиллирование из 500 траекторий агента GPT-6 Astra для стабилизации обучения. Подход подтверждает, что даже небольшие открытые модели могут обучаться превосходить традиционные оптимизаторы в задачах с однозначной метрикой качества — временем выполнения запроса.

Обсуждение ставит под сомнение практическую ценность LLM‐оптимизатора: заявленные 81 % ускорения получены на небольшом наборе (8 ГБ, полностью в памяти), их масштабируемость и экономическая эффективность не доказаны, а риски галлюцинаций и повышенных затрат могут превзойти выгоду. Большинство участников советуют более простые и проверенные подходы: правильное индексирование, классическое ML, гибридные решения и ускорение самого PostgreSQL. Некоторые считают LLM‐подход слишком грубым и ресурсоёмким, предлагая целенаправленные нейросетевые эвристики (похожие на AlphaGo) или видя потенциал LLM в генерации планов. Критики отмечают, что 81 % ускорения не сравнимо с более чем 3‐кратным выигрышем без модели, а затраты на H100 и API могут превысить выгоду. Важно проверять планы, сгенерированные LLM, в изолированной копии продакшн‐БД, чтобы убедиться в ускорении типичных запросов и отсутствии регрессий. Для снижения риска галлюцинаций рекомендуется запускать LLM несколько раз и выбирать лучший план, либо использовать его как подсказку традиционному оптимизатору. Гибридный подход — выбор между традиционным оптимизатором и LLM‐моделью с последующим взятием лучшего плана — рассматривается как более практичный. Также советуют включать опцию RECOMPILE в хранимых процедурах для решения регрессий без LLM. Время планирования является критическим фактором: улучшения планов должны учитывать суммарное время планирование + выполнение. Классические методы ML (модели предсказания стоимости планов) считаются более подходящими, чем крупные языковые модели, для оптимизации запросов. Некоторые предлагают ускорять сам PostgreSQL через CUDA для более прямого прироста производительности. Простое, но часто забываемое правило — правильно индексировать данные; без этого любые улучшения планов будут ограничены.

dbt Charts — это открытый язык на YAML для создания интерактивных дашбордов, разработанный dbt Labs, чтобы соединить свободу кода с управляемостью BI-инструментов в эпоху ИИ-агентов. Он выносит визуализацию из традиционных BI-платформ в код, позволяя агентам генерировать дашборды через чат, сохраняя при этом аудитируемость, версионность и воспроизводимость в Git. SQL остаётся языком для определения данных (WHAT), а YAML описывает их представление (HOW), дополняясь Markdown для текста и Jinja для переменных и макросов — как в dbt.

Язык спроектирован как минимальный, но выразительный набор элементов: переменные для UI-фильтров, именованные запросы и декларативные описания графиков. Пример показывает, как одна переменная, один SQL-запрос и один блок графика формируют полноценный дашборд. Платформа поддерживает conversational analytics — агент с разрешенным только-чтением доступом к warehouse может строить, настраивать и сохранять дашборды через диалог, а затем пользователь может кликнуть, чтобы уточнить детали. Все изменения — будь то из чата, визуального редактора или кода — сохраняются в одном YAML-файле в репозитории, обеспечивая единый источник истины и устраняя необходимость в скрытых стеках данных.

dbt Charts распространяется под лицензией Apache 2.0, работает локально без аккаунта и интегрируется через uv tool install dbt-charts. Бета-версия доступна на GitHub, с документацией, хостингом и сообществом в Slack. Проект пре-1.0, но обратная совместимость обеспечивается миграцией при изменении грамматики. Цель — предоставить открытый слой визуализации, которого не хватало современному стеку данных, чтобы ИИ-агенты могли создавать не просто код, а управляемые, совместные и продуктивные аналитические артефакты.

dbt Charts улучшает аудитируемость и воспроизводимость BI-визуализаций, делая их кодом в Git, что соответствует тренду «unbundling BI». Однако вызывает сомнения выбор YAML как основы DSL: он не поддерживает условные конструкции и привязку переменных, что усложняет шаблоны. Критики отмечают, что продукт не решает ключевые аспекты BI — управление доступом, семантические слои и интерактивность, а лишь отображает сырые SQL-запросы. Некоторые считают, что AI-агенты могут генерировать SVG/HTML-чарты без библиотек, что достаточно для 80% случаев, делая новый формат избыточным. Сравнивают с Malloy, Publisher, VACP, Flint-Chart, Observable Framework и Vega-Lite, где используются более гибкие подходы (Markdown/JS), а также с DaC от Bruin Data как потенциальным конкурентом. Утверждается, что YAML-спецификации напоминают дампы внутренних структур Superset и не предлагают настоящего стандарта. При этом dbt Charts полезен для быстрой генерации метрик в Slack/Teams и интеграции в инструменты генерации приложений, где требуется согласованность стилей. Предлагается использовать его как структурированный формат для внутренних отчётов.

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

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

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

Decker — это платформа для создания интерактивных мультимедийных документов, вдохновлённая HyperCard и визуальной эстетикой классического macOS. Она сочетает простоту и доступность старых инструментов с современными удобствами: глубокой историей отмен, поддержкой сенсорных экранов, масштабируемыми операциями и полноценным скриптованием. Пользователи могут создавать электронные журналы, презентации, текстовые приключения, пиксель-арт или просто экспериментировать — всё сохраняется в самодостаточных HTML-файлах, которые работают в браузере и совместимы с Git. Деки — это не просто документы, а наборы переиспользуемых компонентов, которые легко копировать и адаптировать.

Для сложной логики используется язык Lil — лёгкий, похожий на Lua и Q, с неожиданными удобствами: неявной арифметикой векторов, встроенным SQL-подобным запросом и минимальной кривой обучения. Lil работает и вне Decker через Lilt — автономный интерпретатор, который можно скомпилировать в один исполняемый файл и запустить даже в AWK. Все файлы хранятся в текстовом формате, что делает их идеальными для версионного контроля. Decker лишён рекламы, телеметрии и навязчивых функций — он создан для творчества, а не для монетизации. Среди примеров — Sokoban, Breakout, CHIP-8-интерпретатор и библиотеки для анимации, звука, графиков и визуальных новелл. Платформа открыта под MIT-лицензией, с активным сообществом и ежегодными джемами.

Пользователи отмечают простоту и доступность Decker и её предшественника HyperCard, подчёркивая их потенциал для создания интерактивных мультимедийных документов, презентаций, электронных журналов, игр и образовательных программ. HyperCard использовался для множества инновационных приложений. Некоторые считают Decker устаревшим, другие — потенциально полезным для новых решений, включая сенсорные устройства и образовательный/развлекательный контент. Рекомендуют улучшить дизайн и добавить поддержку сети.

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

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

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

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

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

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

RAG-архитектура, доминировавшая в AI последние три года, уступает место новым подходам. Ранние модели вроде GPT-3.5 ограничивались 4–8 тыс. токенов, что делало невозможной работу с объёмными документами — например, отчёт SEC 10-K содержит ~51 тыс. токенов. RAG решал это через разбиение текста на фрагменты (чанки) и поиск релевантных частей, но даже продвинутые методы чанкинга не спасали от потери контекста: финансовые таблицы, сноски и связи между разделами разрушались.

Современные модели с контекстом в миллионы токенов (например, Gemini 1.5) и агентные архитектуры делают RAG избыточным. Зачем извлекать фрагменты, если можно загрузить весь документ целиком? Это устраняет проблемы чанкинга, эмбеддингов и повторного ранжирования. Ключевой вывод: эра компромиссов между точностью и контекстом заканчивается — будущее за системами, работающими с полными данными без промежуточных шагов.

• Участники критикуют автора за чрезмерное обобщение: утверждение о "смерти RAG" основано на узком примере поиска в коде и не учитывает масштабируемость и другие сложные use-case'ы (например, миллионы документов в распределенных системах).
• Подчеркивается, что RAG — это общий паттерн (извлечение информации + обогащение контекста), а не только векторный поиск; grep, SQL, API-вызовы или использование агента с инструментами — это тоже формы RAG.
• Отмечается, что агентный поиск (с использованием инструментов вроде grep, BM25 и др.) может быть мощнее классического RAG, но он медленнее, дороже и сложнее из-за множественных вызовов функций.
• Указывается, что большие контекстные окна LLM позволяют им читать целые файлы, что меняет workflow и снижает необходимость в сложных пайплайнах чанкинга и эмбеддингов.
• Многие видят иронию в том, что автор называет RAG "кошмаром edge-кейсов", в то время как агентный подход с инструментами вроде grep introduces свои сложности (производительность, безопасность, детерминизм).

TigerBeetle — это финансовый транзакционный движок, построенный на принципах, противоположных общепринятым: медленная разработка кода, детерминированное симуляционное тестирование и нулевые зависимости. Вместо SQL он использует примитивы дебета и кредита, что соответствует изначальной цели транзакционных систем — обеспечению бизнес-операций, как описал ещё Джим Грей в 1985 году.

Традиционные SQL-базы требуют 10–20 запросов для обработки одной финансовой транзакции, создавая узкие места, особенно при работе с «горячими» счетами. TigerBeetle, написанный на Zig, предлагает распределённую архитектуру по умолчанию, статическое выделение памяти и assertions в продакшене. Это ответ на растущие потребности в мгновенных платежах и реальном биллинге, где скорость и надёжность критичны.

• Участники обсуждают технические особенности TigerBeetle, включая его специализацию на финансовых операциях, детерминированное тестирование и минималистичный подход к зависимостям.
• Высказываются критические замечания: отсутствие поддержки многопоточности для масштабирования, проблемы с аутентификацией и совместимостью с облачными платформами, такими как Cloudflare Workers.
• Поднимается вопрос о потенциальной предвзятости статьи, так как её автор является инвестором проекта.
• Отмечается, что традиционные SQL-базы данных по-прежнему эффективно справляются с большинством задач, несмотря на возраст.
• Обсуждаются возможные аналоги TigerBeetle, такие как FoundationDB, и его применимость за пределами финансового сектора.

Иранский разработчик делится опытом блокировок из-за санкций против страны. Microsoft удалила его приложение EyesGuard из магазина без объяснений, стерев аккаунт и отзывы пользователей. Notion полностью очистил его данные, ответив в поддержке, что услуги недоступны для резидентов Ирана из-за ограничений.

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

• Участники обсуждают негативное влияние санкций на обычных граждан Ирана, блокировку сервисов и цифровую изоляцию, отмечая, что санкции вредят населению, а не правящим elites.
• Поднимается тема двойных стандартов: пользователи критикуют тенденцию обвинять народы "стран-изгоев" в действиях их правительств, в то время как действия западных правительств часто отделяются от ответственности их граждан.
• Высказываются опасения по поводу централизации цифровой инфраструктуры в руках США, что дает им возможность в одностороннем порядке определять, кто может пользоваться услугами, и риски такой модели для пользователей из недружественных стран.
• Обсуждается эффективность санкций: многие участники сомневаются, что санкции достигают заявленных целей по изменению политики правительств, а вместо этого лишь укрепляют режимы и усугубляют положение населения.
• Отмечается сложность ситуации для владельцев бизнесов, которые вынуждены блокировать пользователей из-под санкций из-за юридических рисков и штрафов, даже если они не согласны с такой политикой.

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 и за льготную цену.