Какую бд выбрать для телеграм бота?

Давайте сначала разъясним пару моментов:

• СУБД (система управления базами данных) - в этом случае мы имеем ввиду систему, которая занимается хранением данных и дает интерфейс для взаимодействия с ними (примеры: SQLite, MySQL, PostgreSQL). Они бывают серверные и встраиваемые. Реляционными и нереляционными. Почитайте статью про сравнение СУБД, упомянутых выше в качестве примера https://tproger.ru/translations/sqlite-mysql-postgresql-comparison/. Внутри статьи найдется множество ссылок для более подробного изучения. Начните с реляционных баз.

• ORM (object relational mapping) - это прикладная штука, совершенно опциональная для СУБД, позвляющая писать в программе классы, экземпляры которого, выражаясь упрощенно, будут сохраняться в базе данных (популярный пример: SQLAlchemy). Скорее всего это именно то, что имелось ввиду "создавать кодом". Создаются базы данных не кодом, а специальными запросами, например, на языке SQL. Обязанность ORM переводить классы в структуры будущей БД и за программиста генерировать эти запросы.

В общем, если нужна серверная база данных для большого продакшена, то наверняка подойдет MySQL. Вариантом чуть попроще будет - SQLite. Эта СУБД хранит данные в специальном бинарном файле и позволяет не заморачиваться с установкой сервера.

Если коротко - попробуйте для бота сначала SQLite.

Но раз вы сильно начинающий, давайте сначала попробую обьяснить некоторые термины на пальцах.

БД - представьте, что это некий блокнот, тетрадь, книга, что-то такое. Чтобы работать с этим блокнотом, есть ряд инструментов, котрые позволяют создавать данные там (карандаш), хранить большое количество (шкаф), упорядочить для поиска нужного (картотека) и т.п. То есть можно, как вы выразились, создавать БД (блокнот) кодом (руками), можно как то автоматизировать (печатать на принтере) и т.п.

В программировании все очень схоже, но добавляется... наверное назовем это уровнем абстракции. Есть встраиваемые БД (embedded), есть СУБД, в свою очередь они распределяются на реляционные (обычно подразумевают SQL) и нереляционные (NoSQL), которые в свою очередь уже часто разделяют на универсальные и узкоспециализированные.

Выбрать технологию следует исходя из списка задач, при современном развитии вариантов очень много. Либо можно взять что-то относительно устоявшееся и в целом универсальное. Сперва следует задать себе вопрос, кем будет эта БД использоваться - только вашим ботом или еще необходимо, чтобы в/из этой БД писалось/читалось, например, на сайте что-то (другое приложение). Или к примеру, будет много-много ботов, у которых часть данных уникальные, а часть общие.

Соответственно, если БД только для бота, берите встраиваемую БД, тут практически стандартом все советуют SQLite (хотя есть и другие варианты). Это хорошо оптимизированная и отлаженная библиотека, которая работает внутри вашего приложения, хранит данные в одном файле и работает действительно быстро, даже с определенным уровнем защиты от сбоев. Даже больше того, SQLite предоставляет некоторый режим работы, когда к этой БД (файлу) может иметь и другой процесс, не только чтобы прочитать оттуда данные, но даже записать или изменить, одновременно с вашим приложением бота. В общем интересная штука, она сейчас используется повсеместно, в любом телефоне, во многих программах (музыкальные плееры, почтовые программы и т.п.), даже в браузере есть некое ее подобие (WebSQL). Конечно же, есть не только SQLite (например в будущем можно посмотреть на LevelDB, PouchDB, есть множество различных реализаций на разных языках программирования других концепций).

Другой вариант - если вам нужно некоторое централизованное хранилище с одновременным полноценным доступом нескольких разных приложений (несколько ботов, сайт, мобильное приложение и т.п.). Тогда в этом случае либо пишут поверх БД API для обмена данными (чаще просто REST поверх HTTP), либо берут СУБД. Один из самых распространненых вариантов это MySQL или MongoDB. Если хочется чего-то серьезного, то можно попробовать PostgreSQL, если чего-то попроще, не знаю, Redis, CouchDB. Если этот вариант вам нужен, попробуйте какие-то начального уровня программки написать под работу с данными в MySQL или в MongoDB и поймете, что именно из этого вам подойдет. Просто почитайте пару статей типа Getting Started, How to и перепишите оттуда код, запустите и посмотрите результат.

Отличаются они подходом к хранению данные - SQL варианты это таблицы в БД, с заранее определеной структурой (названиями столбцов и типом хранения в них данных), с четким языком запросов на создание, изменение, удаление и поиск данных (SQL это и есть язык запросов). Это SQLite, MySQL, PostgreSQL. NoSQL - это хранение данных с другим подходом. Например, документами целиком, как в MongoDB, PouchDB/CouchDB. Или списком ключ-значение, как в LevelDB, Redis. В вашем браузере тоже есть такие БД, IndexedDB, LocalStorage, SessionStorage, Cookies, все это примеры NoSQL решений. Так что это не что-то "гиковское", но да, со своим подходом, кому то нравится, кому то нет.

У таких БД есть либо свой язык запросов, обычно на базе JSON/JavaScript (поэтому например MongoDB очень популярен у тех, кто пишет на NodeJS), либо совсем простейший GET/SET с вариациями.

Следует еще уточнить, что сейчас уже все не так однозначно, потому что, к примеру в последних версиях MySQL, а в PostgreSQL уже довольно давно, можно хранить в полях документы в JSON формате и даже работать полноценно с полями оттуда, индексировать, искать. Равно как и в NoSQL СУБД есть некое подобие QL-языков запросов, похожих на SQL.

Также появились так называемые ORM, которые добавляют в нужный вам язык программирования еще один уровень абстракции, обычно обьектно-ориентированный. При использовании ORM вы описываете обьекты данных, работаете с полями оттуда и методами, а уже внутри ORM происходит магия и все это сохраняется в какой-то СУБД, причем можно чуть ли не налету менять, в какой СУБД хранить это и вы даже не задумываетесь зачастую, как это проиходит. Хранит и хранит. Это одновременно и удобно и не очень хорошо. Удобно тем, кому заходит ООП, работаешь с обьектами данных и не задумываешься о том, как это хранится. Не очень хорошо тем, что разработчик перестает понимать, как на самом деле происходит работа с данными в используемой СУБД, зачастую теряет на этом определенную долю производительности.

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

Как то так. Написал я вам много, надеюсь не взорвал мозги, но постарался сжато.