В условиях стремительного развития облачных технологий и искусственного интеллекта (ИИ) управление данными становится фундаментом для инноваций. В рамках дискуссии на Startup Grind Майк Фридман, сооснователь и технический директор (CTO) компании Timescale, а также профессор компьютерных наук Принстонского университета, встретился с Френсис Швип из Two Sigma Ventures. Они обсудили трансформацию Timescale из разработчика базы данных в облачную платформу, роль временных рядов в обучении ИИ и ключевые принципы построения продукта, способного конкурировать с технологическими гигантами.
🚀 Timescale: от специализированной базы данных к облачной платформе 1:34
Майк Фридман описывает эволюцию Timescale как переход от «компании, производящей базы данных с облачным дополнением» к «облачной компании с продуктом в виде базы данных» . Основная миссия проекта — «зарядить» PostgreSQL (одну из самых надежных систем с 30-летней историей) возможностями для работы с огромными масштабами современных данных .
Первоначально фокус был направлен на временные ряды (Time Series) и событийные данные, однако Фридман отмечает, что сегодня практически любая база данных объемом в сотни гигабайт состоит из событий:
- E-commerce: история заказов, а не только текущий статус корзины.
- Логистика: каждый этап перемещения товара по миру .
По мнению Фридмана, база данных — это критически важный узел инфраструктуры, на котором строится современное ПО. Френсис Швип добавляет удачную метафору: если обычная база данных делает «фотоснимок» бизнеса, то временные ряды позволяют смотреть «кинофильм» о том, как меняются процессы во времени .
🧠 Роль исторических данных в эпоху ИИ и LLM 4:41
Обсуждая текущий бум искусственного интеллекта, Майк Фридман выделяет два аспекта: использование Timescale клиентами для ИИ-приложений и внедрение ИИ внутри самой компании.
Ключевой тезис Фридмана в этом разделе: создание новых инструментов против адаптации старых . По его мнению, во время появления новых доменов индустрия часто создает «безумное» количество кастомной инфраструктуры, но со временем большинство задач возвращается к проверенным технологиям.
Особое внимание уделяется векторным базам данных:
- Векторные хранилища выступают в роли «памяти» для больших языковых моделей (LLM) .
- Timescale сам использует свой продукт как векторную базу данных для внутреннего чат-бота, обученного на всей документации компании . Это позволяет модели выдавать ответы, основанные на специфическом контенте компании, а не только на общих знаниях GPT.
- Фридман утверждает, что надежной базе данных требуется минимум 10 лет развития, прежде чем ей можно будет доверить критические задачи . Поэтому расширение возможностей PostgreSQL (через Timescale) выглядит более перспективным путем для продакшена, чем использование новых «блестящих» стартапов, которые могут быть нестабильны .
🛠 История создания: пивот от IoT к инфраструктуре 9:13
Компания Timescale не планировала создавать базу данных изначально. В 2015 году Майк и его сооснователь Эй-Джей работали над IoT-платформой (интернет вещей) . Они обнаружили, что на рынке нет инструмента, который бы:
- Был достаточно надежным для операционной деятельности (а не только для исследований).
- Поддерживал SQL.
- Позволял объединять метрики с бизнес-контекстом (метаданными) .
Когда разработчики решили переархитектурировать PostgreSQL для своих нужд и выложили результат в open source, интерес сообщества за первый месяц превысил интерес к их IoT-платформе за предыдущие полтора года . Это стало моментом истины для изменения курса компании.
☁️ Бизнес-модель: Open Source и облачная стратегия 11:23
Фридман считает, что в последние 20 лет инфраструктурное ПО обязано быть открытым (open source), чтобы завоевать доверие разработчиков . Однако выбор бизнес-модели для Timescale был специфичным.
Основные модели open source бизнеса по версии Фридмана:
- Платная поддержка.
- Open Core: часть кода открыта, продвинутые функции (Enterprise) — закрыты.
- Managed Service (Облако): управление инфраструктурой за клиента .
Timescale выбрала путь облачного сервиса. Это позволяет компании контролировать пользовательский опыт (UX) и избавлять разработчиков от операционной рутины — бэкапов, обеспечения высокой доступности (HA) и масштабирования .
Для защиты от «гиперскейлеров» (Amazon AWS, Google Cloud, Azure), которые могут перепродавать чужой open source, Timescale ввела специальную лицензию (Timescale License) . Она позволяет любому человеку использовать код бесплатно и даже в коммерческих целях, но запрещает предлагать Timescale «как услугу» (as-a-service). Это позволило компании держать весь код на GitHub открытым, не разделяя его на части в рамках команды разработки .
🏢 Культура и структура команды 18:27
Переход к модели «только облако» (Cloud-only) радикально изменил структуру организации. Майк Фридман выделяет следующие изменения:
- Инженерия: Для работы в облаке потребовалась отдельная команда. Инженеры теперь несут ответственность не только за код, но и за эксплуатацию (Ops), а циклы релизов стали намного быстрее, чем традиционные квартальные обновления ПО .
- Продажи: Вместо классических корпоративных продаж с многомесячными переговорами Timescale перешла к PLG-модели (Product-Led Go-to-Market) . Клиент просто регистрируется в триальной версии и сразу начинает пользоваться продуктом.
- Процессы: С ростом компании команда перешла от двухнедельных спринтов к квартальному планированию, чтобы синхронизировать разработку с маркетингом и продажами .
💡 Советы фаундерам: о фокусе и смелости 20:41
Глядя назад, Фридман считает главным принципом «Сужение фокуса» (Narrow the focus). Один из его главных уроков — не пытаться делать одновременно и On-premise ПО, и Облачный сервис с самого начала.
Советы Майка Фридмана начинающим предпринимателям:
- Смелость убеждений: Майк сожалеет, что некоторые крупные ставки (например, полный переход в облако) не были сделаны на 6–12 месяцев раньше .
- Избирательность: Цель стартапа — не захватить весь рынок сразу, а завоевать любовь небольшой группы страстных пользователей, используя свою гибкость и скорость .
- Разделение горизонтов планирования: В компании четко разделяют функции на те, что нужны текущим клиентам сегодня, и «ставки на будущее» (горизонт 6–12 месяцев), которые рынок может еще не до конца осознать .
В завершение Майк анонсировал новые разработки в области эластичности инфраструктуры, которые призваны стереть грань между бессерверными (serverless) и выделенными решениями, помогая разработчикам избежать переплат при скачках нагрузки .
