За последние восемь лет более 15 популярных баз данных изменили лицензии с открытых (BSD, Apache) на модели с ограничениями, которые запрещают коммерческое использование или требуют раскрыть весь программный стек. Разработчики выбирают открытые БД, а через несколько лет сталкиваются с необходимостью покупать лицензии или мигрировать — обычно в самый неподходящий момент.
Если вы думаете «сейчас выберем open source, а там разберемся» — этот пост для вас. Я не буду разбирать юридические тонкости, а попробую ответить на простой вопрос — какие БД сегодня опасно брать в прод и чем их можно заменить, если это уже случилось.
Дисклеймер: хронологии и технические характеристики — это факты, которые я собрал из публичных источников. Списки рисков, красные флаги и прогнозы по конкретным вендорам — моя аналитика на основе наблюдаемых паттернов. Ваши выводы могут отличаться, и это нормально.
Какие БД поменяли лицензии: хронология 2016–2025 гг.
Если посмотреть на таймлайн последних лет, картинка получается довольно мрачная.
2016–2018
MariaDB MaxScale (август 2016-го) стал первым крупным кейсом — переход с GPL на Business Source License 1.0. Это был первый звонок, который показал, что даже «защитники» open source в итоге выбирают путь ограничений.
В октябре 2018 года MongoDB сменил AGPL 3.0 на SSPL — лицензию, которая требует открывать весь программный стек, включая инфраструктуру, UI, API и мониторинг при предоставлении сервиса.
В декабре 2018-го Timescale DB разделил продукт: Core под Apache 2.0, а Enterprise функции под проприетарной Timescale License с запретом на DBaaS.
2019–2021
В октябре 2019 года CockroachDB переходит с Apache 2.0 на BSL.
Elasticsearch в январе 2021-го сменил Apache 2.0 на dual license SSPL + Elastic License 2.0 из-за конфликта с Amazon Elasticsearch Service. В 2021-м история повторилась, но уже с другим игроком — Amazon создал форк OpenSearch, который сейчас развивается независимо.
2022–2025
В августе 2023 года HashiCorp переводит Terraform, Vault, Consul и Nomad с Mozilla Public License 2.0 на BUSL 1.1, запретив создание конкурирующих коммерческих продуктов. Linux Foundation ответила форком OpenTofu.
А в декабре 2024 года ScyllaDB объявляет о переходе с AGPL 3.0 на Source-Available License. Начали с ScyllaDB Enterprise 2024.2 в декабре 2024-го, а ScyllaDB Enterprise 2025.1 выходит уже полностью под новой лицензией. Бесплатное использование разрешено в рамках free tier с лимитами: максимум 10 TB хранения (суммарный размер всех серверов ScyllaDB в организации) и до 50 vCPU. По расчетам ScyllaDB, такой кластер может обрабатывать примерно 100–200 тысяч операций в секунду. ScyllaDB OSS 6.2 — последняя версия под AGPL.
Ну и чего стоит всем известный кейс с Redis…
Redis: три лицензии за полтора года
До марта 2024 года проект использовал BSD 3-Clause — полностью открытую permissive лицензию. 20 марта 2024-го Redis Inc. (компания, стоящая за проектом) перешла на двойное лицензирование RSALv2/SSPLv1, начиная с версии Redis 7.4, запретив облачным провайдерам предлагать Redis-as-a-Service без оплаты.
1 мая 2025 года компания совершила второй разворот — Redis 8.0 стал доступен под AGPLv3 как дополнительная опция к существующим RSALv2/SSPLv1. Компания объяснила решение тем, что форки «создали равные условия игры», а сам Redis показал «рекордный рост» после смены лицензии.
Что спровоцировало эти изменения? Сначала это был ответ тем облачным гигантам, которые использовали Redis бесплатно и зарабатывали миллионы — AWS ElastiCache, Azure Cache, Google Memorystore. Компания готовилась к IPO и попыталась монетизировать облачные предложения конкурентов.
Последствия оказались серьезнее, чем ожидалось: проект покинула значительная часть внешних контрибьюторов, а сообщество потеряло доверие. В ответ Linux Foundation при поддержке AWS, Google Cloud, Oracle и Ericsson создала форк Valkey на основе Redis 7.2.4 под BSD-лицензией. Fedora и Debian уже перешли с Redis на Valkey в своих дистрибутивах.
Даже возврат к AGPLv3 как опции и открытый код пока не вернул разработчиков в полной мере. Лично я теперь смотрю на Redis с недоверием и по умолчанию закладываю в новые проекты Valkey.
Какие БД в зоне риска в 2026-м
А вот моя оценка БД на основе наблюдаемых паттернов — речь исключительно о лицензионных рисках и ни разу не о технической стороне вопроса.
Уже изменили лицензию (высокий риск повторения)
CockroachDB — на BSL, Enterprise под CCL без конвертации.
TimescaleDB — dual license, могут расширить proprietary часть.
ScyllaDB — недавно перешли на source-available, могут изменить условия free tier.
MongoDB — на SSPL с 2018, теоретически могут создать еще более restrictive-версию.
ArangoDB — переход с Apache 2.0 на BSL 1.1 в октябре 2023-го, запрет на использование для создания managed service, конвертация обратно в Apache 2.0 через четыре года.
Neo4j — Enterprise Edition под коммерческой лицензией, Community Edition остается по�� GPLv3, но с ограниченным функционалом, 99% кода написано сотрудниками Neo4j Inc.
Под контролем single vendor без community governance
Dragonfly (DragonflyDB Ltd) — пока BSL, молодой проект.
MySQL (Oracle) — GPL, но Enterprise под коммерческой лицензией; Oracle известна агрессивной лицензионной политикой.
Couchbase — Dual licensing (Enterprise + Community Edition с ограничениями), Single vendor без foundation governance.
InfluxDB — модель Dual licensing, Enterprise требует коммерческой лицензии.
ClickHouse (ClickHouse Inc.) — Apache 2.0, но растущая коммерциализация без foundation. Страшно жить…
Минимизируем риски
На этапе выбора БД
Проверяйте governance model и выбирайте foundation-based vs single vendor. Изучайте историю лицензионных изменений вендора и конкурентов. Проверяйте trademark ownership — кто владеет названием проекта. Посмотрите на бизнес-модель: если компания зарабатывает только на Enterprise — риск выше.
Вот мой личный рейтинг БД.
Максимально безопасные: Public Domain (SQLite), permissive с community governance: BSD, MIT, Apache 2.0, PostgreSQL License. Примеры: PostgreSQL, SQLite, Valkey, OpenSearch, Apache Cassandra.
Безопасные с оговорками: OSI-approved copyleft: GPL, LGPL, MPL, AGPL (если устраивает copyleft). Примеры: MariaDB, Redis 8+ (AGPL как опция), Grafana.
Рискованные: Dual license Community/Enterprise от single vendor, BSL с конвертацией. Примеры: TimescaleDB Core, CockroachDB core.
А вот чего лучше избегать, так это: SSPL, BSL без конвертации, source-available с жесткими лимитами, Commons Clause, proprietary Community Licenses. Объясню, почему выделил именно их.
SSPL (Server Side Public License) создана MongoDB и отклонена OSI. При предоставлении сервиса требует открывать весь стек: management, UI, API, automation, мониторинг, бэкапы, хостинг. Для облачных провайдеров выполн��ть это практически невозможно — пришлось бы открывать всю внутреннюю инфраструктуру AWS или Google Cloud.
BSL/BUSL (Business Source License) — source-available-модель с коммерческими ограничениями и отложенной конвертацией в open source (обычно через 2–4 года). Типичные запреты: создание DBaaS, лимит выручки компании (<25M $ для Akka), конкуренция с вендором.
Commons Clause — добавка к Apache/MIT, которая делает лицензию proprietary, запрещая продажу ПО или предложение как SaaS.
Ну и Red flags при выборе, на мой взгляд:
Single vendor без foundation или community governance.
Dual licensing (Community vs Enterprise) как основная бизнес-модель.
Коммерческие модули под restrictive-лицензиями.
Агрессивная риторика против облачных провайдеров в блогах компании.
Недавние инвестиции или подготовка к IPO.
История конфликтов с AWS, Google или Azure.
Copyright Assignment Agreement — в этом случае все права переходят компании.
При использовании в продакшне
В этом случае рекомендую использовать абстракции: ORM, database abstraction layers. Кроме того, избегать vendor-specific-функций или изолировать их в отдельных модулях. Регулярно тестировать совместимость с альтернативными реализациями. Подписываться на новости вендора и следить за license-related issues на GitHub. Раз в квартал пересматривать лицензионную ситуацию и тем самым бюджетировать время на потенциальную миграцию.
И конечно, лучше иметь exit strategy для каждой БД. Понятно, что не у всех есть ресурсы на быструю миграцию, но иметь план Б полезно в любом случае.
Ищем альтернативы
Ниже предлагаю варианты на замену для баз данных, которые уже поменяли лицензию и тех, что находятся в зоне риска (конечно, только тех, для которых эта замена существует в принципе). Для каждой БД я указал:
особенности лицензии, которая была раньше;
почему стоит искать замену;
безопасные альтернативы с открытыми лицензиями и текущие ограничения бесплатных версий, чтобы вы понимали реальную картину.
Redis → Valkey
Текущие лицензии Redis:
edis 7.2 и старше: BSD 3-Clause (последняя открытая версия).
Redis 7.4-7.6: RSALv2/SSPLv1 (запрет managed-сервисов).
Redis 8.0+: RSALv2/SSPLv1/AGPLv3 (тройное лицензирование).
Ограничения: использование Redis 7.4+ для создания облачного сервиса требует либо покупки коммерческой лицензии, либо раскрытия всего кода вашего сервиса.
Valkey — основная альтернатива под BSD 3-Clause с backing Linux Foundation, AWS, Google Cloud, Oracle, Ericsson. Практически полная совместимость с Redis 7.2 на уровне протокола и команд (позиционируется как drop-in replacement, но рекомендую провести собственное тестирование). Уже заменил Redis в Fedora и Debian.
На мой вкус, Valkey — сейчас дефолтный выбор, если вы не привязаны к конкретному облаку и только планируете новый проект.
Другие варианты: KeyDB (Apache 2.0, multi-threaded), Garnet от Microsoft (MIT License), Memcached (BSD) для простого кеширования.
MySQL → PostgreSQL/MariaDB
MySQL принадлежит Oracle с 2010 года. Формально лицензия осталась GPL 2.0, но Oracle выпускает две версии: бесплатную Community Edition под GPL и платную Enterprise Edition под коммерческой лицензией. Oracle известна жесткой политикой извлечения прибыли из своих продуктов и судебными исками против пользователей (вспомните историю с Java и Android). История с форками проектов Oracle (Hudson превратился в Jenkins именно из-за политики Oracle) показывает реальные риски. При использовании MySQL в коммерческом продукте есть риск претензий по GPL, если вы распространяете свой софт без открытия исходников. Многие компании ищут альтернативы именно из-за непредсказуемости Oracle.
Текущие ограничения MySQL Community Edition: отсутствует Enterprise Backup, нет Enterprise Authentication, нет MySQL Enterprise Monitor, урезана поддержка репликации и кластеризации.
PostgreSQL под PostgreSQL License (permissive, как MIT) с governance через PostgreSQL Global Development Group — это наиболее очевидная и проверенная временем альтернатива MySQL. Миграция с MySQL на PostgreSQL хорошо документирована, существуют зрелые инструменты вроде pgloader для автоматической конвертации схемы и данных. PostgreSQL превосходит MySQL по поддержке сложных запросов, JSON-индексов, полнотекстового поиска, window functions и расширяемости через extensions. Основная проблема — синтаксические различия (AUTO_INCREMENT vs SERIAL, разные функции для работы с датами), но они решаются на уровне ORM или адаптации схемы. Для новых проектов PostgreSQL — дефолтный выбор вместо MySQL, если нет жесткой привязки к экосистеме Oracle. Другие варианты: MariaDB (GPL 2.0, fork MySQL до приобретения Oracle, совместимость на уровне протокола), Percona Server (GPL 2.0, drop-in replacement для MySQL с улучшениями производительности).
MongoDB → FerretDB
FerretDB — MongoDB-совместимая БД под Apache 2.0, использует PostgreSQL как backend storage. MongoDB drivers работают без изменений (заявлена совместимость с MongoDB 5.0+, но покрытие API не 100%, тестируйте под ваши запросы). Подходит для большинства CRUD use cases без advanced features типа MapReduce. Конечно, FerretDB еще молодая штука, но для типичных CRUD-сервисов ее уже вполне хватает.
Альтернативы: PostgreSQL + JSONB (native JSON support, мощные индексы, стандартный SQL — мой личный фаворит для новых проектов), CouchDB (Apache 2.0, multi-master replication), ArangoDB (Apache 2.0, multi-model).
Elasticsearch → OpenSearch
OpenSearch — форк Elasticsearch 7.10.2 под Apache 2.0 с backing AWS. Сохраняет API-совместимость на базовом уровне, включает OpenSearch Dashboards (аналог Kibana). Поддерживает distributed search, AI-powered search, security analytics.
Если вы живете в AWS — грех не посмотреть на OpenSearch первым делом.
Альтернативы: Apache Solr (Apache 2.0, зрелая enterprise search, community-driven), Meilisearch (MIT License, fast search), Typesense (GPL 3.0, typo-tolerant), Manticore Search (GPL 2.0).
CockroachDB → YugabyteDB / YDB
YugabyteDB под Apache 2.0 обеспечивает высокую PostgreSQL совместимость (документация заявляет 85%+, что выше чем у CockroachDB ~53%). Поддерживает distributed SQL, multi-region, ACID transactions, автоматический failover.
YDB (Apache 2.0) — distributed SQL база данных от Yandex, прямой аналог CockroachDB и YugabyteDB. Проверена в production на масштабах Яндекса 5+ лет (Алиса, Такси, Маркет, Метрика — почти 500 проектов). Поддерживает ACID-транзакции, строгую консистентность, отказоустойчивость в трех зонах доступности, масштабирование на десятки тысяч серверов. Включает Kafka-совместимый streaming, работу с JSON, PostgreSQL compatibility (в развитии). Для российских компаний YDB — стратегический выбор: технологический суверенитет, русскоязычное community, отсутствие зависимости от западных вендоров, что критично в текущих условиях.
Альтернативы: PostgreSQL + Citus (AGPL 3.0, 100% PostgreSQL совместимость), TiDB (Apache 2.0, MySQL-compatible).
ScyllaDB → Apache Cassandra
Apache Cassandra под Apache 2.0 с governance Apache Software Foundation. ScyllaDB изначально создавалась как Cassandra drop-in replacement, поэтому CQL совместимость сохраняется на уровне протокола. Поддерживает wide-column NoSQL, peer-to-peer distributed, tunable consistency.
Альтернативы: YugabyteDB (YCQL API) (Apache 2.0, Cassandra-compatible API), Apache HBase (Apache 2.0, column-oriented).
TimescaleDB → VictoriaMetrics
TimescaleDB в декабре 2018 года разделила продукт надвое: базовая версия (Core) осталась под Apache 2.0, но все продвинутые функции перешли под закрытую коммерческую лицензию Timescale License. Запрещено создавать облачные сервисы на базе TimescaleDB без оплаты. Со временем все больше функций перемещается в платную часть, что создает риск зависимости.
Текущие ограничения бесплатной TimescaleDB Core: нет непрерывных агрегатов (continuous aggregates), отсутствует сжатие данных (compression), нельзя развернуть кластер на несколько серверов (multi-node), нет продвинутых функций для работы с временными рядами.
Я предлагаю рассмотреть VictoriaMetrics под Apache 2.0. Документация и бенчмарки показывают значительно более высокую производительность, чем у InfluxDB в определенных сценариях (цифры сильно зависят от workload — рекомендую свои тесты). Поддерживает PromQL и Prometheus-совместимость, high-cardinality metrics.
Альтернативы: InfluxDB OSS (MIT License), PostgreSQL с partitioning (полный SQL, ACID), ClickHouse (Apache 2.0, но single vendor — см. раздел «В зоне риска»).
ArangoDB → PostgreSQL + расширения
ArangoDB перешел на BSL 1.1 в октябре 2023 года. Для замены multi-model БД (document/graph/key-value) лучше всего подходит PostgreSQL с расширениями под PostgreSQL License. PostgreSQL нативно поддерживает JSON/JSONB для document storage, расширение Apache AGE (Apache 2.0) добавляет graph capabilities с поддержкой OpenCypher, а встроенный hstore или JSONB покрывают key-value use cases. Это консолидирует три модели данных в одной БД с единым governance.
Другие варианты: CouchDB (Apache 2.0, document-oriented с multi-master replication), Dgraph (Apache 2.0, native graph database с GraphQL).
Neo4j → Memgraph или Apache AGE
Neo4j изначально распространялся под GPLv3, но с ростом проекта компания Neo4j Inc. перешла на двойную модель лицензирования. Бесплатная Community Edition осталась под GPLv3, но с сильно урезанными возможностями. Все важные функции доступны только в платной Enterprise Edition. При этом 99% кода пишут сотрудники Neo4j Inc., а не сообщество — фактически это продукт одной компании.
Текущие ограничения Neo4j Community Edition: нет кластеризации, отсутствуют горячие резервные копии (hot backups), нет продвинутой системы безопасности, ограничена производительность, нельзя использовать в коммерческих managed-сервисах.
Memgraph (BSL 1.1 с конвертацией в MIT через четыре года) позиционируется как совместимая с Neo4j альтернатива с поддержкой Cypher и акцентом на real-time graph analytics. Apache AGE (Apache 2.0) — расширение PostgreSQL для graph queries с поддержкой OpenCypher, позволяет использовать привычную PostgreSQL-инфраструктуру.
Важно: сам Memgraph использует BSL 1.1 (Business Source License) с переходом в MIT через четыре года. Это означает, что свежие версии нельзя использовать для коммерческих конкурирующих продуктов. Для полностью безопасного выбора лучше рассматривать Apache AGE.
Альтернативы: Dgraph (Apache 2.0, native GraphQL support), JanusGraph (Apache 2.0, distributed graph database), ArangoDB (но сам в зоне риска после перехода на BSL).
Couchbase → CouchDB или PostgreSQL
Couchbase изначально создавался как коммерческое ответвление (форк) открытой базы CouchDB. С самого начала использовал двойную модель лицензирования, никогда не был полностью открытым проектом.
Текущие ограничения Couchbase Community Edition: нет межкластерной репликации (XDCR), отсутствует полнотекстовый поиск, нельзя использовать продвинутую аналитику, ограничены возможности безопасности, нет технической поддержки.
CouchDB под Apache 2.0 с backing Apache Software Foundation — прямой предок Couchbase, предлагает document-oriented storage, REST API, multi-master replication и eventual consistency. Для большинства use cases JSON/JSONB в PostgreSQL предоставляет аналогичную функциональность с ACID-гарантиями вместо eventual consistency.
Иные варианты: MongoDB (но на SSPL — тоже в зоне риска), RavenDB (AGPL 3.0 для Community), Apache Cassandra (Apache 2.0, distributed, eventual consistency).
InfluxDB → VictoriaMetrics или GreptimeDB
InfluxDB изначально был полностью открытым под лицензией MIT, но начиная с версии 2.0 компания InfluxData резко изменила подход. Открытая версия (InfluxDB OSS) формально осталась под MIT, но из нее вырезали почти все полезные функции. Все, что нужно для серьезной работы, доступно только в платной Enterprise-версии. База принадлежит одной компании без участия сообщества, что создает высокий риск дальнейших ограничений.
Текущие ограничения бесплатной InfluxDB OSS: нет кластеризации, отсутствует репликация данных между серверами, урезаны возможности безопасности (нет enterprise-уровня аутентификации), нельзя использовать продвинутые инструменты мониторинга и алертинга.
VictoriaMetrics (Apache 2.0) показывает высокую производительность в time-series workloads, поддерживает PromQL и Prometheus-совместимость, high-cardinality metrics. GreptimeDB (Apache 2.0) — cloud-native-альтернатива на Rust с unified observability (metrics, logs, traces), поддержкой SQL/PromQL и оптимизацией под Kubernetes.
Альтернативы: TimescaleDB Core (Apache 2.0, PostgreSQL extension для time-series, но dual licensing — см. раздел рисков), Prometheus (Apache 2.0, metrics и alerting), QuestDB (Apache 2.0, high-performance time-series SQL).
Выводы и рекомендации
За последние несколько лет список БД, когда-то бывших open source, вырос до внушительных размеров. Несмотря на серьезные последствия для экосистемы, вендоры идут на изменения ради краткосрочной прибыли.
В таких условиях я предлагаю выбирать:
БД с foundation/community governance — PostgreSQL и SQLite не изменят лицензию, потому что нет single vendor, который может это сделать единолично. Форки при поддержке foundations (Valkey, OpenSearch, OpenTofu) показывают жизнеспособную модель защиты open source.
Permissive-лицензии: BSD, MIT, Apache 2.0, PostgreSQL License.
Абстракции для упрощения миграции.
Альтернативы с foundation backing для специализированных случаев — они с большей вероятностью останутся открытыми.
Если бы сегодня мне дали чистый проект без ограничений, я бы по умолчанию ставил PostgreSQL — золотой стандарт с permissive-лицензией, community-driven governance, мощным функционалом и огромной экосистемой. Плюс набор проверенных решений open source: Valkey для кеша и OpenSearch для full-text search.
Ну и держал в голове план Б на случай очередного лицензионного сюрприза. А вы бы как поступили?
