🖥 Нашёл любопытный проект: `cq` —-SQL query engine для CSV-файлов, написанный на C.

Что умеет:

- выполнять SQL-запросы прямо по CSV
- фильтровать, агрегировать, делать JOIN’ы
- работать быстро и без “тяжёлых” зависимостей
- подходит для логов, датасетов, ETL-скриптов и ад-hoc анализа

То есть вместо Python-скриптов или импорта в БД —
можно просто кинуть SELECT по файлу и получить результат.

⚡️ Репозиторий: https://github.com/baldimario/cq/

🖥 Большой апдейт для Postgres: нормальный поиск прямо в базе

У Postgres давно есть full-text search, но честно - качество ранжирования часто “так себе”.

Если нужен реально удобный поиск по релевантности, обычно приходилось:
- поднимать Elasticsearch
- или подключать Algolia
- и потом вечно мучаться с синхронизацией данных между системами

Проблема не в том, что Postgres не умеет искать текст.
Проблема в том, что стандартный ts_rank даёт довольно базовое ранжирование и сильно уступает современным поисковикам.

Теперь появилась альтернатива.

Команда TigerDatabase выложила в open-source расширение pg_textsearch - оно приносит BM25 ранжирование прямо в Postgres.

Почему BM25 важно:
BM25 - это алгоритм, который лежит в основе Elasticsearch/Lucene и большинства “нормальных” поисковых движков.
То есть это уже проверенный стандарт качества поиска.

Что даёт pg_textsearch:
- BM25 ранжирование с настройками параметров
- очень простой синтаксис:
ORDER BY content <@> 'search terms'
- работает с multi-language конфигами Postgres
- хорошо сочетается с pgvector для hybrid search (keyword + embeddings)

Для RAG это прям полезно:
можно делать гибридное извлечение в одной базе (Postgres),
без внешнего Elasticsearch и без лишнего glue-кода.

И всё это - open-source под лицензией PostgreSQL.

https://github.com/timescale/pg_textsearch

Горизонтальное масштабирование PostgreSQL — проблема, которая неизбежно возникает при работе с большими данными и высокими нагрузками. Когда количество транзакций растёт до миллионов, стандартных возможностей PostgreSQL уже недостаточно: сопровождение усложняется, риски увеличиваются, а вывод новых продуктов замедляется.
Yandex B2B Tech представили Managed SPQR — управляемый сервис горизонтального масштабирования PostgreSQL на платформе Yandex Cloud. Решение позволяет распределять данные между шардами, автоматически балансировать нагрузку и снимать с команд значительную часть операционных задач.

Managed SPQR помогает:
🔴 ускорить разработку и запуск продуктов в 3–4 раза;
🔴 снизить операционные риски и нагрузку на инфраструктуру;
🔴 сэкономить до 15 млн рублей при запуске высоконагруженных сервисов.
Технология уже используется в проектах Яндекса и у внешних компаний, включая финтех и e-commerce.

📅 5 февраля в 12:00 команда Yandex B2B Tech проведёт вебинар, посвящённый запуску public preview сервиса. Участникам расскажут об архитектуре Managed SPQR, автоматической перебалансировке данных, мониторинге и реальных кейсах, а также разберут выбор ключа шардирования.

🔗 Регистрация и подробности — по ссылке.

⚡️ Масштабирование до 1 000 000 пользователей - практичный подход с PostgreSQL

Автор работал над системой, которая выросла с нуля до более чем миллиона пользователей. Без сложных модных архитектур на старте и без преждевременного оверинжиниринга. Только последовательная эволюция под реальные нагрузки.

В начале всё было максимально просто:

Одно приложение - одна база данных.
И этого было достаточно.

Проблемы появились не в коде. Узким местом стала база данных. Архитектура развивалась шаг за шагом, решая конкретные проблемы по мере их появления.

1️⃣ Старт - один основной инстанс
Использовался один primary-инстанс PostgreSQL. Минимум инфраструктуры, низкие расходы и полный фокус на продукте.

Главная мысль этого этапа - не строить "архитектуру уровня Netflix" для проекта с десятками пользователей.

2️⃣ Разделение чтений - Read Replicas
Когда резко вырос read-трафик:

- Primary обрабатывал только записи
- Реплики обрабатывали SELECT-запросы
- Балансировщик распределял чтения

Кодовая база почти не менялась - менялась маршрутизация трафика.

Результат - база перестала быть узким местом из-за чтений.

3️⃣ Проблема соединений - добавление pgBouncer
При росте числа пользователей упёрлись не в CPU, а в количество соединений.

Каждое соединение к базе - это память и ресурсы. Тысячи коннектов начали "душить" систему.

Решение - connection pooling через pgBouncer:

- Меньше реальных соединений к БД
- Выше пропускная способность
- Меньше сбоев под нагрузкой

4️⃣ Масштабирование через кэш
Чтобы выдержать 1M+ пользователей, стало критично не обращаться к базе за каждым запросом.

Добавили Redis как слой кэширования:

- Часто используемые данные отдавались из кэша
- База перестала быть единственной точкой нагрузки
- Задержки заметно снизились

Именно на этом этапе начинается настоящее масштабирование.

Главный урок

На каждом этапе решалась текущая проблема, а не гипотетическая задача будущего.

| Проблема | Решение |
|---------|---------|
| Много чтений | Read Replicas |
| Слишком много соединений | Пул соединений |
| База перегружена запросами | Кэш |
| Сложная инфраструктура | Не добавлялась без реальной необходимости |

Приложение существует, чтобы поддерживать бизнес.
Если бизнес-модель не работает, никакое масштабирование не спасёт.

Масштабирование - это не про технологии ради технологий.
Это про внедрение решений в тот момент, когда они действительно нужны.

milanjovanovic.tech/blog/scaling-monoliths-a-practical-guide-for-growing-systems