Hacker News Digest

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

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

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

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