Что такое реляционная база данных?

А, слушай, вот тебе на пальцах про эти ваши реляционные базы. Представь себе, блядь, гигантскую библиотеку, только вместо книжек — таблицы, а вместо полок — связи между ними. Вот это и есть RDBMS, ёпта. Данные там не свалены в одну кучу, как носки под кроватью, а аккуратно разложены по ящичкам, которые друг на друга ссылаются. Надёжно, чётко, для всего, что требует порядка, — самое то.

Основные приколы, без которых нихуя не работает:

• Таблица (Relation): Это как раз тот самый ящик. Строки — это записи (вот один пользователь, вот второй), а столбцы — это их свойства (логин, почта, дата рождения). Всё просто, как три копейки.
• Первичный ключ (Primary Key): Уникальный номерок для каждой строки, типа паспорта. Без него — пиздец, кто есть кто не разберёшь.
• Внешний ключ (Foreign Key): А это уже, блядь, хитрая жопа. Это когда в одной таблице столбец тычет пальцем на первичный ключ в другой. Типа «автор этого поста — вот этот чувак из таблицы users». Связь, ёбана!
• SQL: Язык, на котором с этой штукой разговариваешь. «Дай», «положи», «найди», «удали» — всё через него.
• Транзакции и ACID: Вот это, сука, святое. Гарантия, что операция либо выполнится целиком, либо нихуя не выполнится. Деньги со счёта списались, но на другой не зачислились? Не, так не пойдёт, откатываем всё назад. Атомарность, блядь!

Вот смотри, как это выглядит в коде, на примере какого-нибудь бложика:

-- Таблица для юзеров
CREATE TABLE users (
    id SERIAL PRIMARY KEY, -- вот этот самый уникальный номер, паспорт
    username VARCHAR(50) UNIQUE NOT NULL, -- логин, чтобы не повторялся, ёпта
    email VARCHAR(100) NOT NULL
);

-- Таблица для постов
CREATE TABLE posts (
    id SERIAL PRIMARY KEY, -- опять свой паспорт
    title VARCHAR(200) NOT NULL, -- заголовок
    content TEXT, -- сам текст, тут можно овердохуища написать
    author_id INTEGER REFERENCES users(id) ON DELETE CASCADE, -- ВОТ ОН! Внешний ключ. Говорит: "автор — чувак из users". CASCADE значит, если юзера удалили, его посты тоже летят в пизду.
    created_at TIMESTAMP DEFAULT NOW() -- дата создания, автоматом проставляется
);

А теперь, блядь, самое интересное — как это всё в DevOps встраивается? Тут не просто база, а целая ёперный театр!

• Управление схемой (Миграции): Это когда структуру базы (эти самые CREATE TABLE) нужно менять по ходу дела. Добавить столбец, хуй с горы переименовать. Так вот, делается это не руками на проде в панике, а через скрипты-миграции (Liquibase, Flyway). Они версионируются в гите и запускаются в пайплайне. Иначе будет вам хиросима и нигерсраки — одна команда добавила поле, а другая про него не знает.
• Резервное копирование: Автоматизируешь, сука, на все сто. Каждый день pg_dump / mysqldump и складываешь бэкапы в надёжное место. А главное — регулярно проверяешь, что их можно восстановить! Бэкап, который не восстанавливается, — это не бэкап, а хуй в пальто.
• Мониторинг и тюнинг: База тормозит? Надо смотреть, какие запросы ебут ей мозг. Настраиваешь алерты на высокую нагрузку, используешь пулы соединений (PgBouncer), чтобы не открывать новое на каждый чих. Для отказоустойчивости — репликация: одна база главная, другие её копируют, если основная накрылась медным тазом.
• Контейнеризация: Для разработки и тестов — да, удобно запускать базу в докере. Но помни, что это stateful-сервис! Данные-то должны где-то жить, поэтому обязательно маунтишь persistent volumes, а то после перезапуска контейнера окажешься у разбитого корыта.

Из чего обычно выбирают в продакшене? Ну, классика жанра — PostgreSQL (моя любовь, мощная зверюга) или MySQL/MariaDB. Если не хочется самим с бэкапами и обновлениями возиться, то берите managed-сервисы: Amazon RDS или Google Cloud SQL. Они за тебя много чего сделают, но и доверия ебать ноль — читай документацию, а то счёт потом охуеешь получать.