Vector Database Performance Compared: pgvector vs Pinecone vs Qdrant vs Weaviate

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

За последний год автор статьи использовал pgvector в продакшене и параллельно прогнал через тесты несколько альтернатив. Разница между ними есть, но она редко становится решающей на практике.

Pinecone закрывает вопрос инфраструктуры: поднял и работаешь. Это удобно на старте и в прототипах, но за это платишь меньшим контролем над тем, как именно считается recall.

Qdrant заметно выделяется на сценариях с фильтрацией. Если в запросах много условий поверх векторного поиска или нужен self-host, он даёт очень предсказуемую и быструю производительность.

Milvus имеет смысл, когда речь идёт о сотнях миллионов или миллиардах векторов. Там уже важны шардинг и партиционирование, и у него это реализовано зрелее, чем у остальных.

Weaviate упрощает жизнь, если нужен гибридный поиск, когда в одном запросе сочетаются keyword и vector. Плюс у него аккуратно сделан managed-вариант.

pgvector хорошо ложится в существующий стек с Postgres. До примерно 10 миллионов векторов он закрывает задачи без отдельной инфраструктуры. Дальше уже приходится думать про масштабирование, например через pgvectorscale.

Но в реальных системах узкое место другое.

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

Та же история с релевантностью и UX. Переранжирование, нормальная работа с контекстом, понятные ответы, всё это даёт кратно больший эффект, чем выбор между двумя быстрыми базами.

@tldr_data

Краткий обзор на интервью DHH

Удивительно, в это раз про микросервисы не вспомнили и даже переобулись с темой AI.

Вот вообщем короткая выжимка из интервью.

Всего шесть месяцев назад David Heinemeier Hansson (создатель Ruby on Rails и Omarchy) в подкасте Lex Fridman говорил, что не использует AI-инструменты для написания кода — они были недостаточно хороши. Сейчас он работает иначе: agent-first.

Автор подкаста расспросил за ситуацию про то, как изменился его процесс разработки и что он думает о профессии. В этом плане он последователен: тот же фокус на коде как ремесле, на аккуратности и внимании к деталям.

Первое, что бросается в глаза — его отношение к AI почти не поменялось. Поменялись сами инструменты. Полгода назад автодополнение уровня tab completion только мешало: оно сбивает темп и даёт слишком слабые подсказки. Переход к агентным моделям изменил ситуацию. В связке с более сильными моделями, вроде Opus 4.5, результат стал другим: агент генерирует код, который можно принимать без существенных правок. Это уже не подсказки, а полноценные изменения в кодовой базе.

Второй момент — его взгляд на красоту кода.
Для него это не эстетика ради эстетики.
Он формулирует это жёстко: если что-то выглядит правильно, скорее всего, оно и работает правильно. Здесь он ссылается на Steve Jobs — идея о том, что даже внутренняя часть системы должна быть аккуратно сделана.

Люди, которые внимательно разводят платы, как правило, так же внимательно проектируют интерфейсы. Это один и тот же навык, просто в разных слоях.

И, наконец, его текущий workflow. Он работает в tmux с несколькими сплитами. В одном — быстрая модель (обычно Gemini 2.5), которая даёт быстрые итерации. В другом — более медленная, но сильная (Opus), куда уходят сложные задачи. По центру — Neovim, где он просматривает изменения через Lazygit.

Это не выглядит как AI пишет код вместо разработчика. Скорее как система из инструментов с разной латентностью и качеством, между которыми он маршрутизирует задачи.

В итоге меняется не столько роль разработчика, сколько форма работы. Меньше ручного набора, больше проверки, сборки и принятия решений.

Про настройку и кастомизацию терминала будет следующий пост.

@tldr_data

Introducing Metrics SQL: A SQL-based semantic layer for humans and agents

Metrics SQL от Rill создаёт семантический слой, нативный для SQL: бизнес-метрики определяются один раз и затем используются консистентно во всех дашбордах, инструментах и AI-агентах, устраняя расхождения в метриках.

Подход обеспечивает детерминированную, безопасную и производительную аналитику за счёт того, что простые запросы к метрикам компилируются в оптимизированный SQL, исполняемый на стороне базы данных.

@tldr_data

AI CONTEXT ENGINEERING WITH APACHE AIRFLOW

Если вы работаете в analytics engineering, игнорировать AI уже не получится. Но и переоценивать его не стоит.

Сейчас много разговоров про AI-агентов как будущее data engineering. На практике это новый слой над существующей инфраструктурой, а не её замена. Пайплайны, модели данных, качество и lineage остаются. Просто появляется ещё один потребитель - AI.

Ключевое изменение, работа с контекстом.
Модели не знают вашу предметную область.
Их результат напрямую зависит от того, какие данные вы им даёте и как эти данные организованы. Фактически появляется новая задача: готовить данные не только для BI или ML, но и для агентов.

Это выглядит как эволюция привычных процессов. Те же DAG’и в Apache Airflow, но с дополнительными шагами: генерация, проверка, обратная связь. Добавляются практики вроде Agent-as-Judge или Human-in-the-Loop, чтобы контролировать поведение моделей. Это пока не стандарт, а скорее рабочие подходы, которые тестируются в продакшене.

Роль инженера при этом не исчезает. Сдвигается фокус: меньше ручной логики, больше проектирования систем, которые корректно формируют контекст и проверяют результат.

Через две недели Astronomer проведёт бесплатный вебинар по этой теме.

Будут разбирать, как на базе Airflow собрать AI-агента для поддержки: от сбора сырых данных до формирования AI-ready контекста и трассировки решений в виде context graph.

@tldr_data

Launching S3 Files, making S3 buckets accessible as file systems

Amazon S3 Files - это новая возможность, которая позволяет монтировать любой S3-бакет и работать с ним как с полноценной файловой системой напрямую из инстансов EC2, контейнеров или функций Lambda. При этом обеспечивается задержка около 1 мс для активных данных и автоматическая двунаправленная синхронизация между файловой системой и S3-бакетом.

Сервис уже доступен во всех коммерческих регионах AWS и устраняет классический компромисс между преимуществами объектного хранилища S3 и интерактивностью файловых систем. Это делает его особенно полезным для совместных нагрузок - например, AI-агентов и пайплайнов обучения ML, которым требуется общий доступ к данным S3 с низкой задержкой.

@tldr_data

Один из самых внятных бесплатных курсов по AI coding agents

opencode.school - 14 уроков, 7 практических проектов, без регистрации.

Я сам ежедневно использую Claude Code. Но зависеть от одного провайдера готовы не все.

OpenCode - open-source альтернатива, которая работает с 75+ моделями: Claude, GPT, Gemini или локальные модели на вашей машине.

Чем курс отличается:

Вы учитесь прямо внутри инструмента.
Копируете промпты в OpenCode, и он ведёт вас по шагам, параллельно синхронизируя прогресс с сайтом.

Покрывает весь базовый слой: установка, права доступа, кастомные команды, плагины, multi-agent сценарии.

В конце курса, прикладные проекты:
сборка сайтов, автоматизация браузера.

Если вы хотели разобраться с AI-агентами, но откладывали из-за непонятного старта, то это один из самых понятных способов начать.

@tldr_data

Вышел Dagster 1.13

И здесь есть несколько вещей, на которые стоит обратить внимание.

Лично для меня главное обновление, наконец появились partitioned asset checks.
Теперь проверки можно запускать для конкретной партиции upstream-ассета, а не прогонять всё целиком.

Второе большое обновление AI-инструменты.

Команда заопенсорсила dagster-io/skills - репозиторий со знаниями по Dagster, адаптированный под Claude Code, OpenAI Codex, OpenCode и другие агентные инструменты.

Это дополняется расширенным API в dg CLI, который даёт структурированный доступ к job’ам, run’ам, расписаниям, сенсорам и другим сущностям.

Что ещё интересного:

Virtual assets (пока в preview) позволяют описывать database views и другие производные ассеты, которые автоматически обновляются при изменении родительских данных, без явной materialization.
Это убирает давнюю проблему с декларативной автоматизацией и устаревшим статусом view.

State-backed компоненты теперь включены по умолчанию.
Интеграции с dbt, Fivetran, Tableau, Looker и другими инструментами используют сохранённые метаданные вместо повторных запросов к внешним системам.

Также в версиях 1.12.x / 1.13 добавили более 20 новых компонентов: dbt Cloud, Apache Spark (preview), Microsoft Azure, Google Cloud Platform, Databricks, а также расширили поддержку Fivetran и BI-инструментов.

Полный разбор в релизном блоге.

@tldr_data

Docglow — это open-source инструмент, который превращает проекты dbt в более удобную и интерактивную документацию: с визуализацией lineage, поиском и AI-чатом.
Он делает изучение моделей данных проще по сравнению со стандартной документацией dbt.

Это легковесная self-hosted альтернатива более тяжёлым инструментам дата-каталога, с акцентом на удобство как для технических, так и для бизнес-пользователей.

@tldr_data

Database Branching in Postgres: Git-Style Workflows with Databricks Lakebase

Databricks запустили функцию ветвления баз данных (database branching) для Lakebase Postgres, используя механизм copy-on-write для создания изолированных окружений базы данных за считанные секунды без дублирования данных. Это заменяет традиционный подход с использованием pg_dump, который может занимать часы для больших баз данных.

@tldr_data

Технологический стек данных Lyft

Разбор масштабной data-инфраструктуры, которую использует Lyft для поддержки более 25 млн активных пользователей и обработки миллионов событий в реальном времени каждую секунду.

Метрики:

• 28,7 млн активных пользователей в Q3 2025, совершающих ~2,7 млн поездок в день.
• Apache Kafka обрабатывает миллионы событий в секунду для стриминговой аналитики.
• Тысячи пайплайнов на Apache Airflow и Flyte оркестрируют ETL- и ML-процессы.
• Хранилище данных превышает 100+ ПБ в Amazon S3 с использованием Apache Hive Metastore.
• ETL на Trino выполняет ~250 тыс. запросов в день, читая ~10 ПБ/день и записывая ~100 ТБ/день.

@tldr_data

Thoughts on Apache Iceberg Summit 2026

Неделю назад в Сан-Франциско закончился Apache Iceberg Summit 2026.
Два дня саммита позволили выработать общее понимание по обсуждениям, которые доминировали в dev-рассылке всю весну.

Тема опциональности metadata.json в V4 собрала самую большую аудиторию среди всех дизайн-сессий:
эксперты подробно разобрали вопросы переносимости и последствий для статических таблиц, если корневой JSON-файл становится опциональным в случае, когда каталог управляет состоянием метаданных.
Сформировавшееся направление — признать управление метаданными со стороны каталога полноценным режимом first-class, при этом гарантии переносимости сохраняются через явную opt-in семантику, а не текущие предположения по умолчанию.

Дизайн one-file commits — направление, которое Russell Spitzer и Amogh Jahagirdar продвигали через серию предложений — движется к формальному описанию спецификации после согласования, достигнутого на саммите.
Подход заменяет списки манифестов на корневые манифесты и использует delete-векторы манифестов для поддержки коммитов в один файл, что обещает существенное снижение латентности коммитов и объёма хранимых метаданных.
Это одно из наиболее значимых изменений V4 для сценариев с высокой частотой записи, и очные обсуждения позволили закрыть оставшиеся разногласия по поводу inline против внешних delete-векторов манифестов.

Предложение Peter Vary по эффективным обновлениям колонок для AI/ML-нагрузок вызвало заметный интерес на саммите.
Дизайн ориентирован на широкие таблицы, где при каждой записи изменяется лишь подмножество колонок — embedding-векторы, скоринги моделей, значения фичей.
Это позволяет Iceberg записывать только изменённые колонки в отдельные файлы и объединять их на этапе чтения.
Для команд, управляющих feature store’ами петабайтного масштаба, экономия I/O может быть существенной.
Петер отметил, что формальное предложение с POC-бенчмарками появится в dev-рассылке в течение нескольких дней после саммита.

Политика вклада с использованием AI, в обсуждении которой участвовали Holden Karau, Kevin Liu, Steve Loughran и Sung Yun, приблизилась к практическому разрешению.
Саммит дал ту ясность, которой часто не хватает асинхронным обсуждениям, и ожидается, что рабочая версия политики — включая требования к раскрытию информации и стандарты происхождения кода для AI-сгенерированных вкладов — будет опубликована в dev-рассылке уже на этой неделе.

@tldr_data

Polars in Aggregate: Streaming Expands, Lakehouse I/O, and Cloud Profiling

Последний цикл релизов Polars приближает стриминговый движок к использованию по умолчанию за счёт расширения поддержки: теперь доступны streaming merge join, as-of join, а также потоковые чтения и записи (scan/sink) для CSV, NDJSON, IPC и облачных источников.

Также добавлена нативная поддержка roundtrip-операций с Delta Lake и Iceberg, включая прямую ленивую запись (lazy writes) обратно в Delta и функцию sink_iceberg() для построения готовых к коммиту стриминговых пайплайнов.

В Polars Cloud теперь доступен профайлинг запросов с метриками на каждом этапе выполнения: CPU, RAM, сеть и shuffle.

@tldr_data

PgQue – PgQ, universal edition

PgQue — это реализация архитектуры PgQ на чистом PL/pgSQL, предоставляющая высокопроизводительную очередь без разрастания (bloat) для любого экземпляра Postgres 14+.

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

@tldr_data

Анонс для Airflow: новые возможности интеграции AI

Появился новый провайдер Common AI Provider, который добавляет поддержку LLM и агентных сценариев непосредственно в Apache Airflow.
Он построен на Pydantic AI и поддерживает более 20 провайдеров моделей, включая OpenAI, Anthropic, Google, Azure, Bedrock и Ollama.

Новые декораторы
@task.llm — отправка prompt в LLM с возвратом текстового или структурированного результата
@task.agent — запуск автономного агента с инструментами, памятью и многошаговым reasoning
@task.llm_branch — делегирование выбора downstream-задач модели
@task.llm_sql — преобразование естественного языка в валидный SQL-запрос
@task.llm_file_analysis — анализ файлов из object storage (текст, изображения, PDF) с помощью LLM
@task.llm_schema_compare — выявление schema drift между базами данных с использованием LLM-рассуждений
Toolsets

В дополнение к декораторам добавлены toolsets — наборы инструментов, которые агент использует для взаимодействия с внешними системами во время выполнения.

SQLToolset предоставляет read-only доступ к SQL-базам. HookToolset позволяет превращать Airflow Hooks в инструменты агента. MCPToolset подключает агента к MCP-серверу через Airflow connection. DataFusionToolset дает возможность выполнять SQL-запросы по файлам Parquet, CSV и Iceberg без отдельной базы данных. LoggingToolset добавляет логирование всех вызовов инструментов с замером времени выполнения.

@tldr_data

Designing Data-intensive Applications with Martin Kleppmann

Как изменились фундаментальные подходы к построению распределённых систем за последнее десятилетие?
Martin Kleppmann, автор культовой книги Designing Data-Intensive Applications (2017), выпустил в этом месяце второе, существенно обновлённое издание.
В обсуждении он делится тем, как эволюционировали требования и практики построения систем.

Ниже — три ключевых тезиса из разговора:

1. Multi-region и multi-cloud — это не best practice, а компромисс

По мнению Клеппмана, не существует универсального правильного ответа, стоит ли использовать multi-region или multi-cloud архитектуру. Это всегда компромисс между рисками и затратами. Решение должно приниматься на уровне бизнеса, а задача инженеров — уметь чётко формулировать эти trade-offs, а не следовать догмам.

2. Репликация важнее шардинга для большинства команд

Хотя в книге подробно разбирается шардирование, сегодня его необходимость снизилась благодаря развитию облаков. Современные машины стали мощнее, и многие нагрузки помещаются в пределах одного узла.

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

3. Понимание внутренних механизмов систем — конкурентное преимущество

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

В целом, за последние годы акцент сместился с жёстких архитектурных паттернов к осознанному выбору компромиссов, где инженерия тесно связана с бизнес-контекстом.

@tldr_data

dbt-score — линтер для качества метаданных в dbt

dbt-score — это инструмент для оценки качества метаданных в проектах dbt.
Он анализирует модели и проекты по набору правил (документация, тесты, ownership, нейминг, сложность SQL), позволяя командам внедрять стандарты через CI/CD и выявлять проблемные модели на ранних этапах. Поддерживаются кастомные правила для учета внутренних требований и governance-политик.

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

• Комплексный линтинг
Проверяет dbt-объекты по настраиваемым правилам: документация, тесты, структура, нейминг

• Система скоринга
Присваивает числовые оценки (0–10) как отдельным моделям, так и проекту в целом

• Гибкая конфигурация
Настройка правил, уровней строгости и порогов оценки через pyproject.toml

• Интеграция с CI/CD
Возможность падать сборке при несоответствии стандартам качества

• Отслеживание прогресса
Визуальные бейджи и метрики для мониторинга улучшения качества данных со временем

• Расширяемость
Возможность создавать собственные правила под требования конкретной организации

@tldr_data

Kafka + KSQL doing ~200 KB/s in/out costs these guys $120,000 a year 💀

@tldr_data

Rocky — это инструмент на базе Rust, который добавляет управляющий слой поверх хранилищ данных, помогая командам управлять пайплайнами с помощью таких возможностей, как контракты данных, отслеживание происхождения данных (lineage) и безопасное тестирование через ветки.

Он нацелен на раннее выявление ошибок, предотвращение проблем с данными и делает дата-процессы более надежными и понятными.

@tldr_data

В Python-пакет elementary-data, имеющий 1.1 млн загрузок в месяц, внедрён вредоносный код

https://www.opennet.ru/opennews/art.shtml?num=65313

@tldr_data

Очередь за self-hosting: Docker, YAML, ночные падения пайплайнов и ручной дебаг.

Рядом managed-сервис: платишь $20–100 в месяц, нажимаешь deploy и всё работает.

В первом случае экономишь деньги.
Во втором часы жизни.

Self-hosting редко бесплатный.
Просто счёт приходит не в долларах, а в потраченном времени.

@tldr_data