Le Chat: Custom MCP Connectors, Memories 🔥 Горячее
Le Chat: 20+ MCP-коннекторов и Memories
-
Каталог коннекторов (beta)
20+ безопасных интеграций: Databricks, Snowflake, GitHub, Jira, Notion, Asana, Outlook, Box, Stripe, Zapier и др.- Поиск, анализ, действия в одном чате.
- Добавьте собственные MCP-коннекторы.
- Запуск в браузере, мобильном, on-prem или вашем облаке.
-
Memories (beta)
Персонализированные ответы на основе сохранённых фактов и предпочтений.- Контроль: хранить, править, удалять.
- Импорт из ChatGPT.
-
Бесплатно для всех пользователей.
Категории коннекторов
- Данные: Databricks, Snowflake, Pinecone, Prisma Postgres, DeepWiki.
- Продуктивность: Box, Notion, Asana, Monday, Jira, Confluence.
- Разработка: GitHub, Linear, Sentry, Cloudflare.
- Автоматизация: Zapier, Brevo.
- Коммерция: PayPal, Plaid, Square, Stripe.
- Custom: любые MCP-серверы.
Примеры
- Анализ отзывов в Databricks → задача в Asana.
- PR в GitHub → задача в Jira + документация в Notion.
- Сравнение контрактов в Box → краткий отчёт обратно в Box.
- Jira → спринт-обзор в Confluence.
- Stripe → аномалии → задача в Linear.
Управление и безопасность
Админы определяют доступ, аутентификация от имени пользователя.
Развёртывание: self-hosted, ваше облако или Mistral Cloud.
Комментарии (150)
- Пользователи жалуются на провал gpt-5-mini и переходят на mistral-medium-0525: дешевле, быстрее, но при ошибке «падает жёстче».
- Mistral анонсировала 20+ «безопасных» MCP-коннекторов (S3, FTP, SharePoint и др.) и поддержку кастомных удалённых коннекторов.
- Валютация в $14 млрд выглядит низкой против OpenAI/Anthropic; для европейцев главный плюс — «сделано в ЕС».
- Качество моделей: в чате и простых задачах сравнимо с OpenAI, но уступает топ-версиям; скорость реакции высокая.
- Бесплатный тариф и быстрый релиз новых фич отмечают как плюсы, однако многие так и не пробовали Mistral всерьёз.
Data engineering and software engineering are converging
Кратко:
Инженеры, создающие realtime-аналитику или AI-функции, нуждаются в инфраструктуре данных с современным developer experience (DX). MooseStack от 514 — open-source DX-слой для ClickHouse.
Слияние дисциплин
Классические хранилища и озёра строились для аналитиков: SQL, BI-дашборды. Теперь же realtime-данные встроены в продукты и AI-функции, а команды разработки обязаны поставлять их так же быстро, как и обычный код.
- Транзакционные БД (Postgres, MySQL) хороши для разработки, но проваливаются при аналитических нагрузках.
- Облачные аналитические платформы (Snowflake, BigQuery) удобны для пакетных ETL, но не обеспечивают свежесть данных и sub-second ответов, а DX в них устарел.
UX-разрыв
Пользователи хотят аналитику за миллисекунды. ClickHouse решает задачу: на порядки быстрее Postgres и дешевле Snowflake/Databricks.
DX-разрыв
Разработчики привыкли к локальному циклу «код → тест → CI/CD». В мире данных такого нет: нет локального окружения, медленные итерации, конфликты между data- и software-инженерами.
MooseStack
514 выпустили MooseStack — open-source DX-слой поверх ClickHouse:
- Git-native, local-first, everything-as-code.
- Единый язык схем и запросов для всех специалистов.
- Поддержка CI/CD, preview-окружений, автотестов.
Комментарии (50)
- Сторонники «чистого» инженерного подхода считают, что data engineering изначально был частью software engineering, но позже к нему примешались аналитики, знающие лишь SQL/DBT.
- В сообществе виден раскол: одни DE пишут Terraform, CI/CD, Spark и k8s, другие ограничиваются ноутбуками, SQL-запросами и no-code-инструментами.
- Критика Python и SQL как «недостаточно инженерных» языков: динамическая типизация, отсутствие строгих схем и нормального тестирования.
- Название роли «Data Engineer» стало размытым: HR ищут «писателей SQL», а специалисты просят называть их «Software Engineer, Big Data» или «Platform Engineer».
- Сильные практики уже давно используют IaC, версионирование, code review и полноценный SDLC, но таких меньшинство.
Materialized views are obviously useful
Материализованные представления очевидно полезны
Разработчики постоянно перетасовывают данные между системами и форматами.
Возьмём таск-трекер: нужно показывать количество задач в каждом проекте. Сначала всё просто:
const getTaskCountForProject = (id) =>
db.query('select count(1) from tasks where project_id = $1', [id]);
Скорость не устраивает → добавляем Redis-кеш:
const getTaskCountForProject = async (id) => {
const key = `project:${id}:task-count`;
let cnt = await redis.get(key);
if (cnt !== null) return +cnt;
cnt = await db.query('select count(1) ...', [id]);
await redis.set(key, cnt, { ex: 3600 });
return cnt;
};
Пользователи жалуются: счётчик устаревает. Приходится чистить кеш при каждом insert/delete.
Делаем инкрементальные обновления:
await redis.incr(`project:${id}:task-count`);
Но если сервер упадёт между записью в БД и Redis, счётчик сломается навсегда.
Переносим счётчик в ту же БД и обновляем в транзакции, либо пишем триггер — логика в БД снова в моде.
Итог: из одной строки кода выросла куча кода, который нужно поддерживать и синхронизировать.
Таких «побочных» вычислений в приложениях тысячи; они скрывают суть и мешают рефакторингу.
Комментарии (48)
- Пост хвалят за честность, но автор не уточняет СУБД, хотя SQL выглядит как Postgres.
- Postgres-материализованные представления требуют ручного
REFRESH; авто-обновления дают коммерческие продукты (Materialize, Snowflake, MSSQL, ReadySet, Feldera, RisingWave) и расширение pg_ivm. - Convex, Zero и др. используют инкрементное обслуживание представлений (IVM) «под капотом».
- Счётчики через
COUNT(*)без IVM не масштабируются; кто-то предлагает денормализацию и триггеры, кто-то — индексы по FK. - ScyllaDB-материализованные представления считаются багованными; важно понимать конкретную реализацию.
Databricks is raising a Series K Investment at >$100B valuation 💬 Длинная дискуссия
Databricks привлекает раунд Series K при оценке >$100 млрд.
Компания, предоставляющая платформу для аналитики и ИИ, подтвердила переговоры о новом финансировании. Сумма сделки и имена инвесторов пока не раскрываются, но источники называют ориентир выше $100 млрд. Это почти вдвое превышает оценку в $62 млрд, полученную в сентябре 2023 года.
По данным Bloomberg, Databricks выручила за последние 12 месяцев $2,4 млрд, рост 50 % г/г. Компания планирует выйти на IPO в 2025 году.
Комментарии (161)
- Databricks объявил о раунде Series K на $10 млрд при оценке $100 млрд, вызвав волну скепсиса: многие считают это попыткой отложить IPO и избежать реальной оценки.
- Участники обсуждения подчеркивают, что компания за 15 лет и $10+ млрд всё ещё не прибыльна, а продукт (Spark, «обёртки» над Postgres, Lakehouse) кажется переоценённым и дорогим.
- Пользователи жалуются на высокие расходы, долгий запуск задач и сбои в сервисе; конкуренты вроде Snowflake выглядят дешевле.
- Раунд воспринимается как способ «разогнать» оценку и дать ликвидности ранним инвесторам, а не как финансирование роста.
- Сравнения с WeWork, Palantir и OpenAI подчеркивают, что длинные цепочки раундов уже не редкость, но вызывают опасения по поводу «пузыря ИИ».