У 2026 році великі мовні моделі перестали бути лише «розумними автодоповнювачами» коду. Все частіше вони працюють як повноцінні агенти, які самі створюють, змінюють і аналізують бази даних. На каналі Tech With Tim показано, як Claude Code, підключений до AI‑орієнтованого сервісу Ghost.build через MCP‑сервер, отримує власні бази даних, форкає їх, оптимізує запити й тестує міграції — практично без ручного втручання розробника.
Ця стаття зосереджується на практичних робочих процесах: від швидкого прототипування невеликих застосунків до агресивної оптимізації продуктивності й паралельних експериментів з міграціями. Усі приклади виконуються всередині Claude Code, який керує Ghost.build як «бекендом» для даних.
Від «читального щоденника» до аналітики: як Claude сам собі створює бази
Перший рівень можливостей Claude + Ghost.build — це миттєве створення невеликих, але корисних баз даних, які одразу стають інструментом для аналізу.
Показовий приклад — база reading_log. Всередині Claude формулюється проста інструкція: створити нову базу з такою назвою і задати схему для відстеження прочитаних книжок. У таблиці з’являються поля для назви, автора, дати завершення читання та оцінки за п’ятибальною шкалою. Далі Claude, використовуючи інструменти Ghost MCP, не лише створює таблицю SQL, а й самостійно «засіває» її даними — приблизно десятьма книжками про штучний інтелект і машинне навчання.
Ключовий момент у тому, що розробнику не потрібно відкривати окремий клієнт для бази даних, налаштовувати підключення чи писати SQL вручну. Усі команди — створення бази, виконання SQL, вставка даних — виконуються як MCP‑виклики, які Claude ініціює й контролює. Користувач бачить лише результат: готову базу, з якою можна працювати природною мовою.
Далі починається аналітика. На запит про середню оцінку книжок Claude формує й виконує відповідний SQL‑запит, повертаючи середнє значення — близько 4,44 з 5. На прохання відсортувати книжки за рейтингом модель знову звертається до Ghost.build, витягує записи й групує їх за оцінками, показуючи п’ятизіркові, чотиризіркові та тризіркові позиції.
Це виглядає як «розмовний» інтерфейс до бази даних, але під капотом працює цілком реальний SQL‑движок. Ghost.build бере на себе інфраструктуру, а Claude — генерацію запитів і інтерпретацію результатів. Для розробника це означає, що навіть прості особисті інструменти — на кшталт журналу читання — можна підняти за хвилини, не торкаючись конфігурацій БД.
«Movie Night» як прототип: від схеми до Next.js‑дашборду
Другий сценарій показує, як Claude використовує Ghost.build не лише для зберігання даних, а й як основу для швидкого прототипування інтерфейсів.
Створюється нова база Movie Night зі схемою movies, де є поля для назви фільму, режисера, року, жанру, тривалості, а також рейтингу за десятибальною шкалою. Claude отримує завдання засіяти цю таблицю сотнею фільмів, розподілених по різних жанрах і десятиліттях. Знову ж таки, усі операції — створення бази, визначення схеми, вставка сотні записів — виконуються через Ghost MCP без ручного написання SQL.
Далі починається те, що особливо цікавить фронтенд‑розробників: Claude має побудувати простий дашборд на Next.js, використовуючи компоненти shadcn/ui, і підключити його безпосередньо до бази Movie Night. Вимоги до інтерфейсу мінімальні, але показові: одна сторінка з таблицею всіх фільмів, фільтром за жанром і трьома картками зі статистикою — загальна кількість фільмів, середній рейтинг та найпоширеніший режисер.
Claude генерує код Next.js‑сторінки, компоненти інтерфейсу й логіку підключення до бази Ghost.build. Хоча Ghost MCP в першу чергу орієнтований на те, щоб AI‑агент працював із базою безпосередньо, з нього можна витягнути й рядок підключення до underlying‑БД, щоб використовувати її в будь‑якому застосунку.
Результат — робочий, хоч і мінімалістичний дашборд: таблиця з фільмами, можливість сортувати й фільтрувати, базові агрегати зверху. Це не інструмент для продакшн‑аналітики, але як прототип чи внутрішній тул — більш ніж достатньо. Важливо, що весь цикл — від ідеї до UI — проходить у межах одного середовища Claude Code, без ручного налаштування БД, без окремого ORM і без довгих конфігурацій.
Ще одна деталь, яка змінює правила гри: бази Ghost.build зберігаються навіть після того, як сесію Claude Code закрито. Коли інструмент запускається знову, Claude може попросити перелік доступних баз Ghost — і побачить reading_log, Movie Night та інші. Потім їх можна видалити, очистити або форкнути для нових експериментів. Таким чином Ghost.build фактично додає Claude «постійну пам’ять» на рівні даних, якої йому бракує за замовчуванням.
Оптимізація продуктивності: три стратегії, три форки, одна база
Найцікавіші можливості з’являються тоді, коли Claude починає працювати не з іграшковими, а з великими, навмисно повільними базами. Для цього створюється shop_analytics — умовна e‑commerce‑БД, яка має таблиці customers, orders, order_items, products і categories. База відразу наповнюється великим обсягом даних: 100 тисяч клієнтів, 500 тисяч замовлень і 1 мільйон позицій замовлень. При цьому свідомо не додається жодних індексів, окрім первинних ключів, щоб зробити запити повільними.
На цій базі запускається показовий аналітичний запит: знайти топ‑10 клієнтів за сумарними витратами за останні 90 днів, разом із кількістю їхніх замовлень і середнім чеком. Claude формує SQL, виконує його через Ghost MCP і фіксує час: приблизно 1,8 секунди. Для локального експерименту це не катастрофа, але для продакшн‑аналітики — вже відчутна затримка, особливо якщо таких запитів багато.
Далі починається те, що в ручному режимі зазвичай займає години: систематичний перебір стратегій оптимізації. Claude отримує інструкцію:
по‑перше, форкнути базу shop_analytics тричі, причому робити це паралельно, не чекаючи завершення одного форку, щоб почати наступний;
по‑друге, застосувати до кожного форку окрему стратегію оптимізації, не торкаючись базової БД: на одному форку — цільові індекси, на другому — матеріалізований вигляд, на третьому — денормалізована підсумкова таблиця;
по‑третє, на кожному форку повторно виконати той самий запит, заміряти час виконання й порівняти результати.
Ghost.build тут виступає як «лабораторія» для експериментів: форки створюються й видаляються без додаткових витрат на конфігурацію, а Claude керує всім процесом через MCP‑інструменти. Для розробника це означає, що можна дозволити AI‑агенту вільно «ламати» клоновані бази, не ризикуючи продакшном.
Після того як усі три стратегії протестовано, Claude порівнює час виконання запиту на кожному форку й обирає найефективнішу. Далі ця стратегія — наприклад, конкретний набір індексів або схема денормалізованої таблиці — застосовується вже до базової shop_analytics через ті ж MCP‑команди Ghost.build. Тимчасові форки, які використовувалися для експериментів, видаляються, щоб не захаращувати простір і не витрачати ресурси.
Такий підхід змінює саму культуру оптимізації: замість того, щоб інженер вручну вигадував і тестував одну‑дві гіпотези, AI‑агент може паралельно прогнати кілька стратегій на реалістичних даних і повернути не лише «кращу ідею», а й конкретні виміряні прискорення. Ghost.build, зі своєю можливістю створювати й форкати необмежену кількість баз у межах безкоштовного тарифу, робить цю тактику практично безкоштовною.
Паралельні міграції: десять форків для очищення телефонних номерів
Якщо оптимізація продуктивності — це одна сторона роботи з даними, то друга — міграції та очищення. Тут Claude + Ghost.build демонструють ще один потужний сценарій: масові паралельні експерименти з різними стратегіями міграції.
Для цього створюється база users_base з 500 фейковими користувачами. Особливість у тому, що колонка phone_number навмисно «зламана»: приблизно 3% значень — NULL, ще близько 2% — відверто некоректні, а решта — формально валідні, але записані в різних форматах. Це типовий кейс для реальних систем, де телефонні номери накопичуються роками з різних джерел.
Замість того, щоб одразу вирішувати, як саме чистити дані в продакшн‑таблиці, Claude отримує інструкцію форкнути users_base десять разів паралельно, створивши бази migration_test_1 до migration_test_10. На кожному форку можна випробувати окрему стратегію:
на одному — просто видалити всі рядки з некоректними номерами;
на іншому — спробувати заповнити пропуски на основі інших полів;
на третьому — застосувати регулярні вирази для нормалізації форматів;
на четвертому — винести проблемні записи в окрему «карантинну» таблицю, а в основній зберігати лише гарантовано валідні значення;
і так далі, комбінуючи підходи, поки не знайдеться оптимальний баланс між чистотою даних і мінімальними втратами.
Claude, керуючи Ghost MCP, виконує всі ці міграції паралельно, аналізує результати на кожному форку й порівнює, які стратегії дають найкращий компроміс. У підсумку найуспішнішими виявляються підходи, реалізовані в migration_test_5 і migration_test_3. Їх комбінують і застосовують уже до базової users_base, знову ж таки через MCP‑команди до Ghost.build.
Після цього всі десять тестових форків видаляються. У продакшн‑базі залишається лише одна, але вже очищена й нормалізована колонка phone_number, а історія експериментів — у вигляді знань, які Claude може використати в майбутніх міграціях.
Такий підхід до міграцій кардинально відрізняється від традиційного. Замість одного‑двох обережних прогонів на staging‑середовищі з’являється можливість одночасно прогнати десяток варіантів, виміряти їхні наслідки й обрати найкращий. Ghost.build тут знову виступає як «пісочниця» для AI‑агента, де можна безпечно ламати, чистити й перетворювати дані.
Що це означає для розробників і команд
У всіх описаних сценаріях — від reading_log до shop_analytics і users_base — повторюється одна й та сама схема: Claude виступає як «мозок», який генерує SQL, стратегії оптимізації й міграції, а Ghost.build — як «тіло», що забезпечує інфраструктуру баз даних, форки, виконання запитів і зберігання.
Для індивідуальних розробників це означає, що:
можна швидко піднімати невеликі бази для особистих проєктів, нотаток, журналів чи прототипів, не заморочуючись із розгортанням Postgres або MySQL;
можна доручити AI‑агенту не лише писати код, а й повністю керувати життєвим циклом БД — від створення схеми до аналізу даних.
Для команд, які працюють із продакшн‑системами, цікавішими виглядають сценарії з форками:
оптимізація складних аналітичних запитів може перетворитися на систематичний процес, де AI‑агент паралельно тестує індекси, матеріалізовані вигляди й денормалізацію на реалістичних копіях даних;
міграції та очищення даних можна проганяти в десятках варіантів на форках, перш ніж обрати одну‑дві стратегії для застосування до основної бази.
Важливо, що Ghost.build надає безкоштовний тариф із 100 годинами обчислень на місяць, 1 ТБ сховища й необмеженою кількістю баз і форків. Це робить описані експерименти доступними навіть для невеликих команд і фрилансерів, які не готові платити за повноцінні керовані БД лише заради тестів.
У підсумку поєднання Claude Code й Ghost.build демонструє, як AI‑агенти можуть вийти за межі «асистентів програміста» і стати повноцінними операторами даних. Вони не просто пишуть SQL, а будують робочі процеси: створюють бази, форкають їх, тестують стратегії, вимірюють результати й застосовують найкращі рішення до основних систем.
Висновок
Практичні демо з reading_log, Movie Night, shop_analytics і users_base показують, що коли великій мовній моделі дати власну, спеціально спроєктовану для AI базу даних, вона починає працювати зовсім в іншому режимі. Claude не просто відповідає на питання про дані — він сам створює ці дані, структурує їх, оптимізує доступ і проводить міграції, використовуючи Ghost.build як гнучку, безпечну лабораторію.
Для розробників це відкриває новий клас робочих процесів: від швидкого прототипування застосунків до серйозної оптимізації продуктивності й паралельних експериментів із міграціями. І все це — без необхідності вручну керувати інфраструктурою баз даних.
Джерело
YouTube: I gave Claude its own database, here’s what happened