InnoMarts logo
InnoMarts
Fast websites
← Back to course

Backup, restore і базове обслуговування: захищаємо дані PostgreSQL

Backup, restore і базове обслуговування: захищаємо дані PostgreSQL

Повертаємось до PostgreSQL.

У попередній лекції ти вивчив, як PostgreSQL підключається до реальних застосунків.

Ти дізнався про:

Дуже добре.

Тепер твоя база даних може працювати з реальними застосунками.

Це потужно.

Але сила приносить відповідальність.

І іноді паніку.

Бо коли застосунок починає зберігати реальні дані, одне питання стає дуже важливим:

Що буде, якщо щось піде не так?

Таблицю видалили.

Сервер впав.

Погана migration запустилась.

Розробник написав DELETE без WHERE.

Ноутбук помер.

Диск зламався.

Хтось каже:

Я змінив тільки одну маленьку річ.

Дуже небезпечна фраза.

Сьогодні ми поговоримо про backup, restore і базове обслуговування.

Це не найгламурніша частина баз даних.

Ніхто не відкриває курс PostgreSQL і не каже:

Я не можу дочекатися стратегії backup-ів.

Але backup-и нудні тільки до того дня, коли вони тобі потрібні.

Потім вони стають прекрасними.

Як парашут.

Не дуже цікавий під час звичайної прогулянки.

Дуже важливий під час падіння.

Що ти вивчиш

У цій лекції ти вивчиш:

До кінця цієї лекції ти зрозумієш, як захищати свої дані PostgreSQL.

Бо створювати дані — добре.

Використовувати дані — корисно.

Втрачати дані — формує характер.

Але давай уникати надмірного формування характеру.

Чому backup-и важливі

Backup — це копія твоєї бази даних, яку можна використати, якщо щось піде не так.

Проста ідея.

Дуже важлива.

Без backup-ів втрата даних може бути назавжди.

Приклади проблем:

Хтось випадково видалив рядки.
Migration зламала таблиці.
Диск сервера зламався.
База даних пошкодилась.
Неправильна команда видалила таблицю.
Deploy пішов погано.
Production база була перезаписана.

Деякі з цих ситуацій звучать драматично.

Деякі звучать дурнувато.

У реальному житті трапляються обидві.

Комп’ютери ламаються.

Люди помиляються.

Розробники помиляються творчо.

Backup дає шлях назад.

Це не магія.

Але це надія у вигляді файлу.

Backup не справжній, поки restore не працює

Дуже важливе правило:

Backup, який ти ніколи не тестував, — це тільки теорія.

У тебе може бути backup-файл.

Але чи можеш ти його відновити?

Чи містить він ті дані, які ти очікуєш?

Чи він повний?

Чи не занадто старий?

Чи не потребує пароль, який ти забув?

Чи відновлюється він у робочу базу даних?

Якщо ти цього не знаєш, у тебе насправді немає стратегії backup.

У тебе є талісман на удачу.

А PostgreSQL талісмани не вражають.

Тому завжди пам’ятай:

Backup — це перший крок.
Тест restore — це другий крок.

Обидва важливі.

Підготуй demo database

Відкрий PostgreSQL:

sudo -iu postgres psql

Створи demo database:

CREATE DATABASE backup_demo_db;

Підключись до неї:

\c backup_demo_db

Створи таблицю:

CREATE TABLE notes (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Додай трохи даних:

INSERT INTO notes (title, content)
VALUES
  ('First Note', 'This is the first note.'),
  ('Backup Note', 'This row should survive backup and restore.'),
  ('PostgreSQL Note', 'Databases remember things. Sometimes too well.');

Перевір дані:

SELECT * FROM notes;

Тепер у нас є маленька база даних для backup.

Це не дуже важливі дані.

Але хороші для практики.

Практикуйся на фейкових даних.

Не на production.

Production — це не дитячий майданчик.

Production — це місце, де маленькі помилки носять дорогі черевики.

Що таке pg_dump?

pg_dump — це інструмент PostgreSQL, який створює backup бази даних.

Він може експортувати:

структуру таблиць
дані
індекси
constraints
sequences
об’єкти бази даних

За замовчуванням він не робить backup усього PostgreSQL server.

Він робить backup однієї бази даних.

Базова ідея:

pg_dump читає базу даних і записує backup-файл.

pg_dump запускається з terminal.

Не всередині psql.

Це важливо.

Всередині psql ти пишеш SQL-команди.

У terminal ти запускаєш інструменти:

pg_dump
psql
createdb
dropdb
pg_restore

Різні місця.

Різні інструменти.

Та сама базоданна пригода.

Створюємо простий SQL backup

Спочатку вийди з psql:

\q

Тепер запусти це з terminal:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Це створить файл:

backup_demo_db.sql

Це простий SQL backup.

Він містить SQL-команди, які можуть відновити структуру і дані бази.

Можеш його переглянути:

less backup_demo_db.sql

Там можна побачити команди типу:

CREATE TABLE
COPY
ALTER TABLE
CREATE SEQUENCE

Простий SQL backup читається людиною.

Це приємно.

Його можна відновити через psql.

Просто.

Корисно.

Дуже добре для початківців.

Backup з host і port

Іноді треба вказати host і port:

pg_dump -h localhost -p 5432 -U postgres -d backup_demo_db > backup_demo_db.sql

Це означає:

-h localhost       підключитись до localhost
-p 5432            використати port 5432
-U postgres        підключитись як користувач postgres
-d backup_demo_db  зробити backup цієї бази

Якщо використовуєш користувача застосунку, заміни postgres на цього користувача.

Приклад:

pg_dump -h localhost -p 5432 -U app_user -d app_db > app_db.sql

Користувач має мати право читати базу даних.

PostgreSQL не може зробити backup того, що користувач не може бачити.

Дуже справедливо.

Дуже строго.

Дуже PostgreSQL.

Відновлюємо простий SQL backup

Тепер відновимо backup у нову базу даних.

Створи нову базу:

createdb -U postgres backup_demo_restore_db

Тепер віднови:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Це читає SQL-файл і виконує його в новій базі.

Тепер підключись:

psql -U postgres -d backup_demo_restore_db

Перевір дані:

SELECT * FROM notes;

Ти маєш побачити рядки.

Добре.

Ти створив backup.

Ти його відновив.

Ти його протестував.

Це правильний шлях.

Backup без тесту restore — це театр впевненості.

Тест restore — це реальність.

Реальність має значення.

Дратує, але правда.

Приклад DROP і restore

Давай симулюємо катастрофу.

Підключись до відновленої бази:

psql -U postgres -d backup_demo_restore_db

Видали таблицю:

DROP TABLE notes;

Тепер перевір:

SELECT * FROM notes;

PostgreSQL поскаржиться:

relation "notes" does not exist

Дуже сумно.

Дуже навчально.

Вийди:

\q

Віднови знову:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Якщо таблиця вже існує, можна отримати помилки, якщо backup не містить drop-команд.

Для чистішої практики можна пересоздати базу:

dropdb -U postgres backup_demo_restore_db
createdb -U postgres backup_demo_restore_db
psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Потім перевір знову:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

Дані повернулися.

Оце і є магічне відчуття backup-ів.

Не справжня магія.

Краще.

Протестована процедура.

Створюємо backup з --clean

Можна створити backup, який містить команди для видалення існуючих об’єктів перед їх повторним створенням.

Приклад:

pg_dump -U postgres --clean --if-exists -d backup_demo_db > backup_demo_clean.sql

Опції:

--clean       додає DROP-команди
--if-exists   уникає помилок, якщо об’єкти не існують

Це може полегшити restore поверх існуючої бази.

Але будь обережний.

Backup з DROP-командами може видалити існуючі об’єкти під час restore.

Можливо, саме цього ти хочеш.

А можливо, так твій день стане дуже захопливим.

Завжди знай, що робить твій backup-файл.

SQL-файли — це не декорація.

Вони виконуються.

PostgreSQL слухається.

Емоційна підтримка не входить у комплект.

Backup у custom format

PostgreSQL також підтримує backup у custom format.

Створи його так:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Тут:

-F c              custom format
-f file_name      output file

Це створить:

backup_demo_db.dump

Цей файл не є звичайним читабельним SQL.

Але він гнучкий.

Його відновлюють через pg_restore.

Custom format корисний, бо можна:

відновлювати вибрані таблиці
відновлювати з більшою кількістю опцій
використовувати parallel restore у більших випадках
переглядати вміст backup

Для багатьох реальних проєктів custom format — хороший вибір.

Менш читабельний.

Більш потужний.

Як стиснута скринька інструментів для бази даних.

Відновлюємо custom format backup

Створи нову базу даних:

createdb -U postgres backup_demo_custom_restore_db

Віднови через pg_restore:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Тепер підключись:

psql -U postgres -d backup_demo_custom_restore_db

Перевір дані:

SELECT * FROM notes;

Ти маєш побачити свої дані.

Добре.

Тепер ти знаєш обидва стилі:

простий SQL backup -> restore через psql
custom backup      -> restore через pg_restore

Просте правило.

Дуже корисне.

Простий SQL vs custom format

Простий SQL backup:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Restore:

psql -U postgres -d new_db < backup_demo_db.sql

Добре для:

простих backup-ів
навчання
людинозчитуваних файлів
маленьких баз даних
легкої перевірки

Custom format backup:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Restore:

pg_restore -U postgres -d new_db backup_demo_db.dump

Добре для:

більших баз даних
гнучкішого restore
відновлення вибраних об’єктів
production-style workflow

Обидва варіанти корисні.

Не перетворюй це на релігійну війну.

Бази даних і так мають достатньо драми.

Перегляд вмісту custom backup

Можна переглянути custom backup:

pg_restore -l backup_demo_db.dump

Це показує, що є всередині backup.

Ти можеш побачити таблиці, sequences, constraints і data sections.

Це корисно, якщо хочеш зрозуміти, що містить backup.

Бо “сподіваюся, там є таблиця” — це не стратегія.

Перевір.

Підтвердь.

Потім спи спокійніше.

Можливо.

Назви backup-файлів

Використовуй зрозумілі назви файлів.

Погано:

backup.sql
new_backup.sql
backup_final.sql
backup_final_REAL.sql
backup_please_work.sql

Добре:

backup_demo_db_2026-05-03.sql
shop_db_2026-05-03_22-30.dump
portfolio_db_before_migration_2026-05-03.dump

Додавай:

назву бази даних
дату
час, якщо корисно
причину, якщо корисно

Приклад:

pg_dump -U postgres -F c -d shop_db -f shop_db_2026-05-03.dump

Хороші назви рятують мозок.

Погані назви створюють археологію.

А ніхто не хоче розкопувати backup-файли о 2 ночі.

Стискаємо простий SQL backup

Прості SQL backup-и можуть бути великими.

Їх можна стиснути:

pg_dump -U postgres -d backup_demo_db | gzip > backup_demo_db.sql.gz

Відновлення стисненого backup:

gunzip -c backup_demo_db.sql.gz | psql -U postgres -d backup_demo_restore_db

Це корисно для економії місця на диску.

Але пам’ятай:

Стиснені файли теж треба тестувати.

Стиснений зламаний backup усе одно зламаний.

Просто менший.

Дуже ефективний смуток.

Backup перед небезпечними змінами

Перед ризикованими операціями створи backup.

Приклади ризикованих операцій:

велика migration
видалення колонок
зміна типів даних
mass update
mass delete
переробка schema
production deploy
імпорт зовнішніх даних

Приклад backup:

pg_dump -U postgres -F c -d shop_db -f shop_db_before_migration_2026-05-03.dump

Потім роби небезпечну зміну.

Якщо щось піде не так, у тебе є точка повернення.

Це професійно.

Це спокійно.

Це спосіб не увійти в історію бази даних поганим способом.

Небезпечний приклад DELETE

Це небезпечно:

DELETE FROM customers;

Це видаляє всі рядки з customers.

Можливо, ти мав на увазі:

DELETE FROM customers
WHERE id = 5;

Маленька різниця.

Величезний результат.

Перед виконанням небезпечних команд використовуй transaction, коли можливо:

BEGIN;

Виконай команду:

DELETE FROM customers
WHERE id = 5;

Перевір:

SELECT * FROM customers;

Якщо все правильно:

COMMIT;

Якщо помилка:

ROLLBACK;

Transactions можуть врятувати від деяких помилок.

Backup-и можуть врятувати від більших помилок.

Обидва корисні.

Як ремінь безпеки і airbag.

Не вибирай тільки одне, бо почуваєшся хоробрим.

Базова стратегія backup

Проста backup strategy має відповідати на питання:

Як часто ми робимо backup?
Де ми зберігаємо backup-и?
Як довго ми їх зберігаємо?
Хто має доступ до backup-ів?
Як ми робимо restore?
Чи ми тестували restore?

Для маленького проєкту можна робити:

щоденний backup
зберігати останні 7 daily backups
зберігати weekly backup протягом 1 місяця
зберігати backup-и поза сервером
регулярно тестувати restore

Для серйозніших проєктів потрібен сильніший план.

Але навіть простий протестований план набагато кращий, ніж:

Мені здається, server provider щось має.

Можливо, має.

Можливо, ні.

Можливо, це коштує додатково.

Можливо, воно ніколи не було увімкнене.

Можливо, воно відновлює весь server, але не ту одну базу, яка тобі потрібна.

Перевір.

Не припускай.

Припущення — двоюрідний брат катастрофи.

Зберігай backup-и в безпечному місці

Якщо база даних і backup на одному сервері, а сервер помирає, можна втратити обидва.

Погано.

Кращі місця для backup-ів:

інший сервер
зовнішнє сховище
безпечне cloud storage
зашифроване backup storage
offline copy для важливих даних

Мінімум — не тримай єдиний backup поруч з оригінальною базою.

Це як тримати запасний ключ від дому всередині будинку, який горить.

Технічно запасний.

Практично не дуже корисний.

Захищай backup-файли

Backup-и містять дані.

Іноді чутливі дані.

Це означає, що backup-файли треба захищати.

Правила:

не виставляй backup-и публічно
обмежуй доступ
використовуй сильні permissions
подумай про encryption
безпечно видаляй старі backup-и
не надсилай database dumps через email бездумно

Backup бази даних може бути таким же чутливим, як live database.

Іноді навіть більш чутливим.

Бо люди забувають, що він існує.

Атакувальники не забувають.

Дуже нечемно з їхнього боку.

Але правда.

Базове обслуговування: VACUUM

PostgreSQL використовує систему, де оновлені й видалені рядки залишають старі версії рядків.

Це частина того, як PostgreSQL працює з concurrency.

Дуже розумно.

Але це означає, що PostgreSQL потребує прибирання.

Це прибирання називається:

VACUUM

Запусти:

VACUUM;

Це очищає dead rows у поточній базі даних.

Більшість PostgreSQL installations мають autovacuum увімкнений.

Autovacuum працює автоматично.

Добре.

Бо ручне пам’ятання всього — це спосіб, яким люди програють.

Все одно корисно знати, що робить VACUUM.

Він допомагає PostgreSQL тримати таблиці здоровими.

Як прибирання майстерні.

Не гламурно.

Дуже потрібно.

VACUUM ANALYZE

Можна запустити:

VACUUM ANALYZE;

Це робить дві речі:

VACUUM очищає dead row versions.
ANALYZE оновлює planner statistics.

Planner statistics допомагають PostgreSQL вибирати хороші query plans.

Якщо statistics застарілі, PostgreSQL може робити погані вибори.

Наприклад, використовувати неправильний індекс.

Або сканувати забагато.

Або загалом виглядати розгубленим бухгалтером.

ANALYZE допомагає PostgreSQL краще розуміти дані.

База зі свіжими statistics — щасливіша база.

Напевно.

PostgreSQL не усміхається.

Але продуктивність може покращитися.

ANALYZE окремо

Можна запустити:

ANALYZE;

Це оновлює statistics без vacuum.

Також можна проаналізувати одну таблицю:

ANALYZE products;

Це корисно після великих змін даних.

Приклад:

імпортовано багато рядків
видалено багато рядків
оновлено багато рядків
змінився розподіл даних

PostgreSQL використовує statistics, щоб вирішувати, як виконувати запити.

Погані statistics можуть давати погані plans.

Погані plans дають повільні queries.

Повільні queries дають сумних розробників.

Ланцюжок зрозумілий.

REINDEX

Індекси іноді можуть роздуватися або потребувати перебудови.

У PostgreSQL є:

REINDEX

Приклад:

REINDEX DATABASE backup_demo_db;

Або один index:

REINDEX INDEX index_name;

Або одна table:

REINDEX TABLE table_name;

Не запускай REINDEX випадково кожні п’ять хвилин.

Це не чистити зуби.

Використовуй його, коли потрібно.

Для початківців достатньо знати:

REINDEX перебудовує індекси.

У реальному обслуговуванні треба розуміти, навіщо ти це робиш.

Сліпе обслуговування все одно сліпе.

Навіть якщо носить серйозний капелюх.

Перевіряємо розмір бази даних

Можна перевірити розмір бази:

SELECT pg_size_pretty(pg_database_size('backup_demo_db'));

Перевірити розміри таблиць:

SELECT
  relname AS table_name,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Це допомагає зрозуміти, що займає місце.

Іноді найбільша таблиця — це очікувано.

Іноді це log table, яку ніхто не чистив три роки.

Бази даних збирають історію.

Іноді забагато історії.

Як шухляда зі старими кабелями.

Перевіряємо активні підключення

Можна побачити активні підключення:

SELECT
  pid,
  usename,
  datname,
  state,
  query
FROM pg_stat_activity;

Це показує, хто підключений і що робить.

Корисно для debugging.

Можливо, застосунок має забагато підключень.

Можливо, query зависла.

Можливо, хтось відкрив psql і пішов обідати.

PostgreSQL знає.

PostgreSQL пам’ятає.

PostgreSQL мовчки судить.

Знаходимо повільні queries

PostgreSQL може логувати повільні queries, якщо це налаштовано.

Поширене налаштування:

log_min_duration_statement

Приклад ідеї:

логувати queries повільніші за 1000 ms

Зазвичай це налаштовується у PostgreSQL configuration files.

Для початківців важлива ідея така:

Повільні queries треба спостерігати, а не вгадувати.

Використовуй інструменти:

EXPLAIN ANALYZE
logs
monitoring
pg_stat_statements

pg_stat_statements — це extension, який допомагає відстежувати query performance.

Це вже більш advanced.

Але добре знати, що воно існує.

Робота з performance без спостереження — це database astrology.

А database astrology ми вже не довіряємо.

Backup and maintenance checklist

Простий checklist:

Створюй регулярні backup-и.
Зберігай backup-и поза database server.
Захищай backup-файли.
Тестуй restore.
Роби backup перед migrations.
Використовуй app-specific users.
Тримай PostgreSQL оновленим.
Монітор disk space.
Дивись slow queries.
Дозволь autovacuum працювати.
Запускай ANALYZE після великих imports, якщо потрібно.
Документуй restore steps.

Documentation важлива.

Процедура restore не має жити тільки в твоїй голові.

Особливо якщо твоя голова втомлена.

Або у відпустці.

Або п’є каву, поки production горить.

Запиши кроки.

Майбутній ти заслуговує на милість.

Типові помилки з backup-ами

Ніколи не тестувати restore

Це найбільша помилка.

Backup-файлу недостатньо.

Треба знати, що він відновлюється.

Тестуй restore на іншій базі.

Приклад:

createdb -U postgres restore_test_db
pg_restore -U postgres -d restore_test_db shop_db_2026-05-03.dump

Потім перевір дані.

Довіряй, але перевіряй.

А точніше, з backup-ами:

Не довіряй.
Перевіряй.

Тримати backup-и тільки на тому самому сервері

Якщо сервер помре, можна втратити базу і backup разом.

Погано.

Зберігай копії десь іще.

Backup має пережити поломку оригінальної машини.

У цьому весь сенс.

Робити backup-и занадто рідко

Якщо робити backup раз на місяць, можна втратити місяць даних.

Можливо, це прийнятно для іграшкового проєкту.

Не прийнятно для реального магазину.

Обирай частоту backup-ів залежно від того, скільки даних можна дозволити собі втратити.

Це питання має серйозну назву:

Recovery Point Objective

Проста версія:

Яка втрата даних є прийнятною?

Якщо відповідь “майже ніяка”, потрібна серйозна стратегія.

Не знати, скільки триває restore

Backup може існувати.

Але restore може займати час.

Для маленьких баз — можливо, секунди.

Для величезних баз — можливо, години.

Якщо застосунок недоступний, час restore важливий.

Це питання має ще одну серйозну назву:

Recovery Time Objective

Проста версія:

Як довго система може бути offline?

Тут business people раптом дуже цікавляться базами даних.

Цікаво, як це працює.

Робити backup не тієї бази даних

Класична помилка.

Ти думаєш, що зробив backup production.

А насправді зробив backup local development.

Backup містить трьох test users і продукт з назвою “banana”.

Перевір:

SELECT current_database();

Перевір назви backup-файлів.

Перевір результат restore.

Не припускай.

Практика

Створи backup backup_demo_db:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Створи restore database:

createdb -U postgres backup_demo_restore_db

Віднови:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Перевір:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

Створи custom backup:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Створи ще одну restore database:

createdb -U postgres backup_demo_custom_restore_db

Віднови:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Перевір:

psql -U postgres -d backup_demo_custom_restore_db

SELECT * FROM notes;

Запусти maintenance:

VACUUM ANALYZE;

Перевір розмір бази даних:

SELECT pg_size_pretty(pg_database_size(current_database()));

Це практично.

Це не гламурно.

Це корисно.

Як хороша викрутка.

Знову.

Бази даних люблять викрутки.

Метафорично.

Міні-завдання

Створи backup plan для маленької blog database.

Уяви:

database name: blog_app_db
дані змінюються щодня
blog маленький
втрата більше ніж одного дня даних — це погано
deploy відбувається щотижня

Напиши простий backup plan:

Backup frequency:
Backup format:
Backup location:
Retention:
Restore test frequency:
Backup before migrations:
Who can access backups:

Приклад відповіді:

Backup frequency: daily
Backup format: custom format через pg_dump -F c
Backup location: external secure storage
Retention: зберігати daily backups 7 днів і weekly backups 1 місяць
Restore test frequency: раз на місяць
Backup before migrations: завжди
Who can access backups: тільки administrator

Тепер створи backup command:

pg_dump -U postgres -F c -d blog_app_db -f blog_app_db_2026-05-03.dump

Створи restore test command:

createdb -U postgres blog_app_restore_test_db
pg_restore -U postgres -d blog_app_restore_test_db blog_app_db_2026-05-03.dump

Потім напиши check query:

SELECT COUNT(*) FROM posts;

Так ти починаєш думати як людина, відповідальна за дані.

Трохи страшно.

Дуже корисно.

Дуже доросло.

Підсумок

Сьогодні ти вивчив:

Ця лекція надзвичайно важлива.

Можливо, не блискуча.

Але важлива.

Розробник, який уміє створювати таблиці, корисний.

Розробник, який уміє робити запити, кращий.

Розробник, який уміє захищати і відновлювати дані, набагато надійніший.

Бо реальні проєкти — це не тільки будувати.

Це ще й виживати після помилок.

І backup-и — один з найкращих способів вижити.

Підсумок курсу

Ти дійшов до кінця цього курсу PostgreSQL.

Ти вивчив:

Це багато.

Ти вивчив не просто команди.

Ти навчився думати про дані.

Це важливо.

Бо застосунки приходять і йдуть.

Framework-и змінюються.

Frontend trends змінюються кожні п’ятнадцять хвилин.

Але дані залишаються важливими.

PostgreSQL — серйозний інструмент.

Тепер ти знаєш достатньо, щоб почати використовувати його серйозно.

Обережно.

Практично.

І з backup-ами.

Завжди з backup-ами.

Фінальні слова

PostgreSQL не завжди буде легким.

Іноді він буде скаржитись.

Іноді він відхилить твій query.

Іноді він скаже:

syntax error at or near...

і ти дивитимешся на одну кому десять хвилин.

Це нормально.

Ти вивчаєш реальний інструмент.

Потужний інструмент.

Інструмент, який використовують у реальних застосунках, реальних компаніях, реальних API, реальних dashboard-ах і реальних системах, де дані мають значення.

Продовжуй практикуватися.

Створюй маленькі проєкти.

Ламай речі.

Відновлюй їх.

Пиши queries.

Використовуй EXPLAIN ANALYZE.

Роби backup-и.

Тестуй backup-и.

Поважай дані.

І пам’ятай:

Browsers forget.
Databases remember.
Backups forgive.

Дуже PostgreSQL.

Дуже практично.

Дуже добре.