Команда LibreDB Studio сделала неудобную, но полезную вещь: вместо красивой универсальной таблицы она начала честно показывать, где движок умеет работу, а где интерфейсу просто нечего обещать.
Суть события
LibreDB Studio — это self-hosted IDE для СУБД, которая работает в браузере и разворачивается рядом с базами. И как только в одном окне собираются сразу 14 принципиально разных движков, от реляционных PostgreSQL, MySQL и SQLite до MongoDB, Redis, Cassandra, ClickHouse, Druid, Elasticsearch, OpenSearch и Trino, появляется очень знакомый соблазн: упростить всё до одного аккуратного интерфейса и дорисовать недостающие детали потом.
Но команда пошла другим путём. Вместо единой выдуманной модели они сделали контракт результата и capability map: драйвер возвращает не только данные, но и честный список того, что умеет, чего не умеет и где ответ вообще неприменим. Это звучит менее эффектно, чем единая таблица для всех, зато не превращает продукт в машину по производству ложных ожиданий.
Детали
Самые болезненные места оказались предсказуемыми. Для Druid, Elasticsearch и OpenSearch интерфейс не притворяется, что можно редактировать строку там, где поддержки UPDATE и DELETE нет по природе движка. Кнопка редактирования просто не появляется, а не прячется за фальшивым спиннером. Это скучнее, но именно так и выглядит нормальная инженерная честность: пользователь сразу видит read-only режим, а не красивую ловушку.
Отдельная история — Cassandra. Точного count(*) там нет в готовом виде, а оценка по метаданным может сильно промахнуться. Команда проверила это на тестовой таблице и увидела, что приблизительное число легко уводит в сторону. Поэтому в браузере счётчик строк не показывают вовсе. Trino тоже не пытаются натянуть на привычную схему: у него нет собственных таблиц, ключей и индексов, и панель это прямо говорит, а не оставляет пустые поля для домыслов.
Контекст
У этой истории есть важный продуктовый смысл. Совместимость по wire-протоколу не означает одинаковое поведение. MySQL-совместимый SingleStore, Cassandra-совместимая ScyllaDB или MongoDB-похожий FerretDB могут вести себя достаточно по-разному, чтобы один и тот же интерфейс начал врать, если его не ограничить контрактом. Поэтому у команды нет лозунга «»поддерживаем 33 движка»» без звёздочки — есть ручная таблица совместимости, где проверена каждая панель метаданных.
Для пользователя это выглядит почти незаметно: меньше кнопок, меньше пустых обещаний, меньше удивления. Но для продукта это огромная разница. Когда интерфейс показывает не желаемую картину, а реальное состояние движка, команды поддержки получают меньше спорных кейсов, а разработчики — меньше соблазна строить процессы на неверных данных. В похожем тоне мы уже разбирали, как фоновые задачи в ChatGPT стали понятнее, когда их перестали маскировать под универсальный поток.
Что дальше
Главный вывод здесь очень практичный: если продукт работает поверх разных систем, его сила не в том, чтобы все они выглядели одинаково, а в том, чтобы различия были видны сразу. Это экономит время на онбординге, снижает риск неправильных решений и помогает честнее продавать возможности команды без обещаний, которые потом придётся объяснять в переписке и на созвонах.
Для B2B-рынка это особенно заметно. Клиент покупает не абстрактную красоту интерфейса, а предсказуемость поведения. Если операция не поддерживается, лучше сказать об этом сразу. Если число нельзя посчитать точно, лучше не показывать его вообще. Именно такая скучная точность и создаёт доверие, а вместе с ним — шанс, что продукт будут использовать долго, а не только до первого разочарования.
