Serwery MCP dla baz SQL i NoSQL
Serwery MCP dla baz danych pozwalają narzędziom AI odczytać żywy schemat i wykonywać zapytania tylko do odczytu, zamiast zgadywać strukturę tabel. Zespoły na PostgreSQL sięgają po Prisma MCP lub Supabase MCP, projekty MongoDB po serwer MongoDB MCP, SQLite obsługuje prototypowanie, a dbhub łączy kilka silników. Wynikają z tego dwa workflow: model danych z prawdziwej tabeli i debugowanie na żywych danych.
Twoje AI właśnie napisało piękne zapytanie ORM do tabeli, która nie istnieje. Założyło, że users.email jest unikalne, choć schemat dopuszcza duplikaty. Napisało z pamięci interfejs User, który zgaduje, że email nie może być pusty, pomija kolumnę miękkiego usuwania deleted_at i typuje created_at jako string, podczas gdy to timestamptz. Dziesięć minut później debugujesz zablokowane zamówienia, a ono radośnie proponuje zapytanie do tabeli payment, która naprawdę nazywa się payments.
Każda z tych wpadek ma tę samą przyczynę: AI zgaduje Twoje dane, zamiast je czytać. Serwer MCP dla bazy danych zamyka tę lukę. Gdy AI może odczytać schemat i wykonywać zapytania tylko do odczytu, przestaje wymyślać i zaczyna pracować na tym, co naprawdę jest.
Co dają serwery MCP dla baz danych
Dział zatytułowany „Co dają serwery MCP dla baz danych”- Konfigurację dla PostgreSQL (Prisma i Supabase), MongoDB, SQLite i dbhub w Cursorze, Claude Code i Codeksie
- Ramy decyzyjne do wyboru właściwego serwera dla Twojego stacku
- Postawę bezpieczeństwa „tylko do odczytu”, która czyni to wszystko bezpiecznym na środowisku staging
- Powtarzalny proces generowania dokładnego modelu danych — typy, dopuszczalność null, wartości domyślne — z żywej tabeli
- Pętlę debugowania na żywych danych, która znajduje wadliwe wiersze w minuty zamiast ręcznie pisanych joinów
- Prompty do generowania kodu świadomego schematu, szkicowania migracji i doraźnych analiz danych
Wybór właściwego serwera MCP dla Twojego stacku
Dział zatytułowany „Wybór właściwego serwera MCP dla Twojego stacku”| Stack | Rekomendowany MCP | Dlaczego |
|---|---|---|
| TypeScript + Prisma | Prisma MCP | Natywna integracja z Twoim ORM-em i systemem migracji |
| Supabase | Supabase MCP | Respektuje polityki RLS, zawiera narzędzia auth i storage |
| MongoDB | MongoDB MCP | Wnioskowanie schematu, zapytania JSON, analiza kolekcji |
| SQLite / lokalny dev | SQLite MCP | Zero konfiguracji, idealny do prototypowania |
| Wiele baz danych | dbhub | Uniwersalny konektor wspierający PostgreSQL, MySQL, SQLite i inne |
Rejestracja ma ten sam kształt dla każdego z nich i jest jednym z tych miejsc, w których trzy narzędzia naprawdę się zbiegają. Cursor i Claude Code czytają ten sam JSON mcpServers, więc blok z Cursora możesz wkleić do .mcp.json Claude Code bez zmian — albo użyć claude mcp add, żeby CLI zapisało go za Ciebie. Różni się tylko format Codeksa: TOML [mcp_servers.<id>], w którym transport stdio jest wnioskowany z command i nie ma klucza transport.
PostgreSQL: Prisma MCP i Supabase MCP
Dział zatytułowany „PostgreSQL: Prisma MCP i Supabase MCP”Dla zespołów TypeScript najnaturalniejszym wyborem jest serwer Prisma MCP. Integruje się z istniejącym schematem Prismy i pozwala AI odpytywać dane, przeglądać schematy i zarządzać migracjami.
{ "mcpServers": { "prisma": { "command": "npx", "args": ["-y", "prisma", "mcp"] } }}claude mcp add prisma -- npx -y prisma mcp[mcp_servers.prisma]command = "npx"args = ["-y", "prisma", "mcp"]Dla zespołów na Supabase serwer Supabase MCP jest świadomy polityk Row Level Security i szerszego ekosystemu Supabase, w tym auth, storage i edge functions.
MongoDB MCP
Dział zatytułowany „MongoDB MCP”Dla baz dokumentowych serwer MongoDB MCP zapewnia przeglądanie schematu i zapytania JSON. Pomaga AI poruszać się po półustrukturyzowanych kolekcjach i rozumieć wzorce dokumentów zagnieżdżonych.
{ "mcpServers": { "mongodb": { "command": "npx", "args": ["-y", "mongodb-mcp-server"], "env": { "MONGODB_URI": "mongodb://localhost:27017/mydb" } } }}claude mcp add --env MONGODB_URI=mongodb://localhost:27017/mydb mongodb -- npx -y mongodb-mcp-server[mcp_servers.mongodb]command = "npx"args = ["-y", "mongodb-mcp-server"]
[mcp_servers.mongodb.env]MONGODB_URI = "mongodb://localhost:27017/mydb"SQLite MCP
Dział zatytułowany „SQLite MCP”SQLite to pewny wybór do lokalnego rozwoju i prototypowania. Pozwól AI eksperymentować ze schematami i budować narzędzia wewnętrzne bez dotykania danych produkcyjnych.
{ "mcpServers": { "sqlite": { "command": "uvx", "args": ["mcp-server-sqlite", "--db-path", "./dev.db"] } }}claude mcp add sqlite -- uvx mcp-server-sqlite --db-path ./dev.db[mcp_servers.sqlite]command = "uvx"args = ["mcp-server-sqlite", "--db-path", "./dev.db"]Najpierw tylko do odczytu, i staging zamiast produkcji
Dział zatytułowany „Najpierw tylko do odczytu, i staging zamiast produkcji”Gdy to jest gotowe, oba workflow poniżej można bezpiecznie uruchamiać na prawdziwych danych, bo nic w żadnym z nich nie może niczego zmienić.
Workflow 1: model danych wygenerowany z żywej tabeli
Dział zatytułowany „Workflow 1: model danych wygenerowany z żywej tabeli”Potrzebujesz modelu User, który dokładnie odpowiada tabeli users — a nie najlepszemu przypuszczeniu AI.
-
Niech AI odczyta prawdziwy schemat. Odczyt na początku sprawia, że wygenerowany kod jest osadzony w rzeczywistych kolumnach, typach i dopuszczalności null.
-
Wygeneruj model z tego kontekstu. Teraz AI ma prawdę w kontekście, więc typy się zgadzają.
Wynik odpowiada Twojej tabeli, bo został z niej wygenerowany — kolumny nullowalne są opcjonalne, znacznik czasu to
Date, adeleted_atjest udokumentowane, a nie pominięte.
Gdy chcesz zapytania, a nie modelu, ta sama dyscyplina zwija się do jednego promptu: najpierw odczytaj schemat, potem napisz zapytanie.
Workflow 2: debugowanie problemu produkcyjnego na żywych danych
Dział zatytułowany „Workflow 2: debugowanie problemu produkcyjnego na żywych danych”Część zamówień utknęła i podejrzewasz dane, a nie kod. Zamiast pisać joina ręcznie, opisz objaw i pozwól AI zbudować oraz uruchomić zapytanie.
-
Opisz zły stan zwykłym językiem. AI tłumaczy go na SQL, uruchamia przez serwer MCP na połączeniu tylko do odczytu i pokazuje wadliwe wiersze.
Prośba o wypisanie wykonanego SQL to różnica między czarną skrzynką a narzędziem, któremu możesz ufać — logikę joina weryfikujesz sam, zanim uwierzysz w wynik.
-
Ruszaj dalej od dowodu. Mając konkretne identyfikatory zamówień, zawężasz dalej bez przepisywania czegokolwiek ręcznie.
Diagnozę postawiłeś na żywych danych, nie wychodząc z edytora i nie pisząc ręcznie joina po wielu tabelach.
Ta sama pętla działa dla doraźnej analizy, nie tylko dla błędów:
Migracje i rozjazd schematu
Dział zatytułowany „Migracje i rozjazd schematu”Trzecia korzyść to wyłapywanie luki między tym, co trzyma baza, a tym, co twierdzą Twoje typy. AI czyta obie strony naraz, czego samodzielnie nie robi ani narzędzie do migracji, ani type-checker.
Przeczytaj wygenerowany SQL, zanim go uruchomisz. Raport o rozjeździe to dowód; migracja to zmiana.
Gdy serwery MCP dla baz danych zawodzą
Dział zatytułowany „Gdy serwery MCP dla baz danych zawodzą”Connection refused. Upewnij się, że baza działa i jest osiągalna z localhosta. Sprawdź, czy connection string niesie właściwy port, nazwę bazy i poświadczenia.
AI odpytuje tabelę lub kolumnę, która nie istnieje. Wciąż zgaduje, zamiast czytać schemat. Wymuś krok odczytu: niech przeczyta schemat, zanim napisze jakiekolwiek zapytanie, i potwierdź, że serwer MCP jest faktycznie podłączony (klient powinien wyświetlać jego narzędzia).
AI pisze destrukcyjne zapytania. Jeśli wykonuje UPDATE albo DELETE, gdy oczekiwałeś tylko SELECT, użytkownik bazy ma za dużo uprawnień. Utwórz dedykowaną rolę tylko do odczytu na potrzeby MCP.
Odczyt schematu zwraca nieaktualne dane. Część serwerów MCP cache’uje metadane schematu. Po migracji zrestartuj serwer, żeby odświeżyć cache, i ponów prompt odczytujący schemat.
Wolne zapytania przekraczają timeout. Skany analityczne na dużych tabelach potrafią przekroczyć timeout narzędzia. Dodaj indeks, zawęź WHERE albo poproś AI o LIMIT i stronicowanie.