← Vissza a cikkekhez
technologytutorial

SQL Connect — SQL a Firebase-ben

Zsaga
#featured#firebase#sql-connect#data-connect#postgresql#graphql#cloud-sql#type-safe-sdk#realtime#firestore-comparison#hibrid
Firebase SQL Connect — háromszintű ábra: kliens SDK fent, SQL Connect szolgáltatás középen, felügyelt Cloud SQL PostgreSQL alul, GraphQL séma előnézettel
A séma egyszerre adja az adatbázist, az API-t és a kliens SDK-t
Mit tanulsz
  • sql-connectBevezető

01 — Bevezetés

Mi az SQL Connect?

A Firebase SQL Connect egy felügyelt szolgáltatás, ami egy GraphQL séma alapján generál neked PostgreSQL adatbázist, a hozzá tartozó biztonságos szerver-végpontokat, és típusbiztos kliens SDK-kat — webre, iOS-re, Androidra és Flutterre. Mintha egy „magától vezető szerver" lenne, a saját alkalmazásodra szabva.
A név változott
A szolgáltatást eredetileg Firebase Data Connect néven mutatta be a Google a 2024-es I/O-n, és sokáig így volt ismert. A 2025 áprilisi GA-elérést követően Firebase SQL Connect lett a hivatalos név. A funkciók és az API-k változatlanok, a meglévő integrációk továbbra is működnek. A régi blog-bejegyzésekben, tutorialokban és YouTube-videókban még mindig „Data Connect" néven szerepel — ezért érdemes mindkét nevet ismerni.

Honnan jött?

A Firebase eredetileg a NoSQL világhoz tartozott. A Firestore dokumentumalapú, a Realtime Database egy fa szerkezet — egyik sem tudja jól modellezni azokat a klasszikus üzleti rendszereket, ahol sok kapcsolat, sok join és sok aggregáció kell. Aki egy ilyet épített Firebase-en, kénytelen volt vagy denormalizálni mindent, vagy egy külön Cloud SQL-t felhúzni a háta mögé saját REST API-val.
Az SQL Connect 2024 májusában jelent meg a Google I/O-n előzetesként (még Data Connect néven), 2024 októberében nyilvános preview lett, és 2025 áprilisában GA. Ez a Firebase első relációs adatbázis-megoldása, és egyben az első, amiben a kliens nem közvetlenül beszél az adatbázissal — egy GraphQL réteg ül közöttük, ami a szerveroldalon dolgozza fel a kéréseket.

Az alapfilozófia: query-defined infrastructure

Az SQL Connect mögötti gondolat új a Firebase ökoszisztémában: query-defined infrastructure. Te leírod, milyen adatmodelled van, és milyen lekérdezéseket akarsz futtatni — az SQL Connect ebből legenerálja a teljes infrastruktúrát.
Mit jelent ez konkrétan?
  • A séma alapján elkészíti a PostgreSQL táblákat (DDL automatikusan).
  • Ad egy biztonságos GraphQL végpontot, ami csak az általad előre definiált queryket és mutationöket fogadja.
  • Generál egy típusbiztos kliens SDK-t — webre, iOS-re, Androidra, Flutterre —, amiben minden lekérdezés egy tipizált függvény.
  • Kezeli a séma-migrációkat — ha módosítod a típusokat, az SQL Connect tudja, mit kell a PostgreSQL-en is megváltoztatni.
A Firestore-hoz képest fontos különbség: ott a kliens egy „nyitott ajtó" előtt áll, és csak a Security Rules akadályozza meg, hogy bármit lekérdezzen. Az SQL Connect-ben a kliens csak előre definiált műveleteket hajthat végre. Ez egészen más biztonsági modell.
Mit tanulsz
  • postgresqlBevezető
  • cloud-sqlBevezető

02 — PostgreSQL

A háttérben: Cloud SQL PostgreSQL

Az SQL Connect alatt egy igazi, teljes értékű PostgreSQL fut, a Google Cloud SQL felügyelt szolgáltatásán. Ez azt jelenti, hogy minden, amit egy Postgres tud — kiterjesztések, indexek, full-text search, JSON, tranzakciók — a tied.

Mit kapsz a Postgres-ből?

  • Erős konzisztencia — ACID tranzakciók, foreign key megszorítások, unique indexek. Pénzügyi adatra vagy üzleti adatra alkalmasabb, mint a Firestore.
  • Bonyolult lekérdezések — joinok, subqueryk, window functionök, CTE-k, aggregációk. Mind, ami SQL-ben szokásos.
  • PostgreSQL-kiterjesztések — PostGIS földrajzi adatokhoz, pgvector embedding kereséshez, full-text keresés (tsvector/tsquery), és bármi, amit a Cloud SQL támogat.
  • Adatmodell-portolhatóság — ha valaha el akarsz költözni a Firebase-ből, a Postgres adatbázis exportálható és bárhova áttehető. Ez sokkal könnyebb, mint egy Firestore-export.

Két séma-üzemmód

Az SQL Connect kétféleképpen tudja kezelni a PostgreSQL és a saját séma viszonyát:
Üzemmód

Strict mode vs. compatible mode

Strict mode

Az SQL Connect séma vezeti a PostgreSQL sémát. Te csak a GraphQL típusokat módosítod, a Postgres séma magától követi. Új projektekhez ideális — egy hely, egy igazság.

Compatible mode

A PostgreSQL séma az igazság forrása, az SQL Connect csak egy részét teszi elérhetővé. Akkor jó, ha már van meglévő Cloud SQL adatbázisod, amit a klienseknek elérhetővé teszel.

Migrációs út
Ha van már egy működő PostgreSQL adatbázisod (akár Cloud SQL-en, akár máshol), nem kell mindent újraírni. Compatible mode-ban az SQL Connect-et eléteheted, és csak azokat a táblákat „nyitod meg" GraphQL-en keresztül, amiket a kliens elérhet — a többi sora és táblája rejtve marad. Ez egy fokozatos modernizációs út lehet.
Mit tanulsz
  • sql-connectKözéphaladó
  • graphqlKözéphaladó

03 — A séma

A séma — relációs gondolkodás újra

Az SQL Connect séma egy GraphQL fájl, amiben a típusokra @table direktívát teszel. A típusok lesznek a táblák, a mezők lesznek az oszlopok, és a más típusra mutató mezők lesznek a foreign key-ek. Mintha egy SQL DDL-t írnál — csak sokkal olvashatóbban.

Egy egyszerű séma

dataconnect/schema/schema.gqlgraphql
type User @table {
  id: UUID! @default(expr: "uuidV4()")
  uid: String! @col(name: "firebase_uid") @unique
  displayName: String!
  email: String! @unique
  createdAt: Timestamp! @default(expr: "request.time")
}

type Post @table {
  id: UUID! @default(expr: "uuidV4()")
  title: String!
  content: String!
  author: User!                       # foreign key to User
  publishedAt: Timestamp
  tags: [String!]!                    # text[] PostgreSQL array
}

type Comment @table {
  id: UUID! @default(expr: "uuidV4()")
  text: String!
  post: Post!                         # M-1 relation
  author: User!
  createdAt: Timestamp! @default(expr: "request.time")
}
Ebből a sémából az SQL Connect generál neked egy users, posts és comments táblát Postgres-ben, foreign key megszorításokkal. A @default direktíva azt mondja, hogy a createdAt magától a kérés idejét veszi fel, az id pedig egy UUID lesz. A @col egy másik oszlopnévre térképez (ha SQL oldali konvenciót akarsz tartani: snake_case).

Many-to-many kapcsolatok

Az SQL-ben megszokott módon, kapcsolótáblával:
m2m-examplegraphql
type Tag @table {
  id: UUID! @default(expr: "uuidV4()")
  name: String! @unique
}

# Junction table with composite key
type PostTag @table(key: ["post", "tag"]) {
  post: Post!
  tag: Tag!
  addedAt: Timestamp! @default(expr: "request.time")
}
Az SQL Connect ebből generál egy implicit posts_via_PostTag mezőt a Tag típusra, és egy tags_via_PostTag-et a Post típusra. A klienskódban így ezek explicit join nélkül elérhetők.
Olvashatóság
A séma egy GraphQL fájl, ezért könnyen olvasható. Ha a csapatban van valaki, aki nem PostgreSQL-fejlesztő, ezt akkor is megérti — szemben egy SQL DDL fájllal, ahol az indexek, megszorítások és foreign key-ek között könnyű elveszni. Ez az SQL Connect egyik mellékhozadéka: az adatmodell dokumentációként is működik.
Mit tanulsz
  • sql-connectKözéphaladó

04 — Queries és mutations

Előre definiált queryk és mutationök

Az SQL Connect-ben minden lekérdezést és írási műveletet előre definiálsz egy GraphQL fájlban, és deploy-kor ezek a szerverre kerülnek — mintha kis Cloud Function-ök lennének. A kliens csak ezeket hívhatja meg, nyers GraphQL queryt nem küldhet. Ez egészen más, mint egy klasszikus GraphQL szerver.

Egy egyszerű query

connectors/posts/queries.gqlgraphql
query GetRecentPosts($limit: Int! = 20) @auth(level: PUBLIC) {
  posts(
    orderBy: [{ publishedAt: DESC }],
    where: { publishedAt: { ne: null } },
    limit: $limit
  ) {
    id
    title
    publishedAt
    author {                       # automatic join
      displayName
    }
    comments_count                 # auto-generated aggregate
  }
}
Mit lehet itt látni? A 4. sorban a where egy SQL-szerű szűrés, ami GraphQL-ben kifejezve. A 10-12. sor egy implicit join — kéred a szerző nevét, és az SQL Connect mögötte lefuttat egy JOIN users-t. A 13. sor egy aggregátum: az SQL Connect minden kapcsolatra automatikusan generál egy _count mezőt, és számoszlopokra _sum, _avg, _min, _max mezőket is. SQL-ben ez egy JOIN ... GROUP BY lenne, itt egy szó.

Mutationök

connectors/posts/mutations.gqlgraphql
mutation CreatePost(
  $title: String!,
  $content: String!,
  $tags: [String!]!
) @auth(level: USER) {
  post_insert(data: {
    title: $title,
    content: $content,
    tags: $tags,
    author: { uid_expr: "auth.uid" }    # from the JWT
  })
}
A mutationben láthatod az SQL Connect egyik kulcsmechanizmusát: a auth.uid-ra hivatkozhatsz közvetlenül. A szerző ID-jét nem a kliens küldi (mert hamisítható lenne), hanem az SQL Connect szerver olvassa ki a JWT-ből. Ez egészen más, mint egy klasszikus REST API-ban, ahol az ilyen ellenőrzést neked kell elvégezned a backend kódban.

Aggregate fields — beépített statisztikák

Az SQL Connect minden mezőre generál bizonyos aggregátumokat:
Mező típusaGenerált aggregátumok
Bármi<field>_count — non-null sorok száma
Számok (Int, Float, Int64)_min, _max, _sum, _avg
Kapcsolat (1-N)<rel>_count, <rel>_aggregate { ... }
Ezek a Firestore-ban csak külön count(), sum() hívásként érhetők el, és külön költségen. Az SQL Connect-ben egy lekérdezésen belül tetszőlegesen variálhatod őket, plusz költség nélkül.
Mit tanulsz
  • sql-connectHaladó

05 — Native SQL

Native SQL — ha tényleg kell

Az SQL Connect GraphQL-je nagyon kifejező, de néha kell valami, amit nehéz GraphQL-ben megfogalmazni — egy bonyolult ablak-függvényes lekérdezés, egy PostgreSQL-extension használata, vagy egy stored procedure. Erre van a native SQL út, ami közvetlenül beilleszt SQL-t a műveletekbe.
native-sql-examplegraphql
query TopAuthorsByPostCount($limit: Int!) @auth(level: PUBLIC) {
  authors: _select(
    sql: """
      SELECT
        u.id, u.display_name,
        COUNT(p.id) AS post_count,
        RANK() OVER (ORDER BY COUNT(p.id) DESC) AS rank
      FROM users u
      LEFT JOIN posts p ON p.author = u.id
      GROUP BY u.id, u.display_name
      ORDER BY post_count DESC
      LIMIT $1
    """,
    params: [$limit]
  )
}
Ez egy ablak-függvényes lekérdezés, amit GraphQL-ben kifejezni nem lenne könnyű. Native SQL-lel közvetlenül a Postgres erejét használod, miközben az SQL Connect kliens-felület és a jogosultságkezelés érintetlen marad.

Mire való és mire nem?

  • Jó használati esetek: komplex riportok ablak-függvényekkel, PostGIS földrajzi keresések, full-text keresés tsvector-rel, stored procedure-ök hívása, performance-kritikus, kézzel optimalizált lekérdezések.
  • Kevésbé jó: egyszerű CRUD műveletek (a sima GraphQL kényelmesebb), bármi, ami típusbiztos eredményt igényelne (a native SQL lazább típusokkal tér vissza).
Korlátok
A native SQL-ben tilos a -- sor-komment (csak /* ... */ blokk-komment), és a paramétereket $1, $2 stílusban kell megadni — ez biztonsági ellenőrzés a SQL-injection ellen. Ha kommentbe rakott egy paramétert is, az operation hibázni fog, mert a params tömbben még szerepel.
Mit tanulsz
  • realtimeKözéphaladó

06 — Valós idejű lekérdezések

Valós idejű lekérdezések — a GA újdonsága

A Firestore egyik legerősebb tulajdonsága a valós idejű feliratkozás: egy lekérdezés magától frissül, ha az adat változik. Sokáig úgy tűnt, hogy ezt SQL-ben nem lehet jól megcsinálni — de az SQL Connect GA-jában már működik, és a klienskód szempontjából nézve teljesen ugyanaz, mintha Firestore-ral dolgoznál.

Hogy néz ki egy valós idejű query?

webapp/src/Posts.tsx (example)typescript
import { subscribeGetRecentPosts } from '@my-app/dataconnect';

// A traditional query: runs once, result comes back
const { data } = await getRecentPosts({ limit: 20 });

// A realtime query: subscribe, every change is pushed
const unsub = subscribeGetRecentPosts(
  { limit: 20 },
  ({ data }) => {
    setPosts(data.posts);          // React state update
  }
);

// Cleanup when the component unmounts
unsub();
A klienskód szempontjából majdnem ugyanaz, mint a Firestore onSnapshot-ja — feliratkozol, callback érkezik minden változásnál, és van egy unsubscribe függvény. A háttérben az SQL Connect figyeli a Postgres változásait (CDC, change data capture), és csak azokat a változásokat pusholja, amik a query eredményét tényleg érintik.

Mire való?

A valós idejű lekérdezések olyan használati esetekben jönnek jól, ahol a felhasználó azonnali frissítést vár:
  • Live leaderboard — egy játék pontszámlistája, ami változik közben.
  • News feed — új posztok, amik magától megjelennek.
  • Kollaborációs felület — több felhasználó együtt szerkeszt valamit, és látják egymás módosításait.
  • Adminisztrációs dashboard — rendelési statisztikák, amik élőben frissülnek.
Költség és optimalizáció
A valós idejű feliratkozás nem ingyen van — minden adatváltozást elvileg ki kell értékelni az aktív feliratkozások ellen. Az SQL Connect viszont csak akkor pusholja az adatot, ha a változás tényleg érinti a query eredményét — ezért kell a queryket úgy megfogalmazni, hogy specifikusak legyenek (pl. where szűrésekkel), ne pedig „minden poszt" stílusúak.
Mit tanulsz
  • sql-connectKözéphaladó

07 — Jogosultság

@auth — jogosultság a séma szintjén

A Firestore Security Rules egy külön fájlban él. Az SQL Connect-ben a jogosultságkezelés közvetlenül a query és mutation definícióban van, @auth direktívával. Mindegyik művelet mellé odaírod, kinek szabad lefuttatnia. Ez egészen más szemlélet — szorosabb integráció, kevesebb párhuzamosan karbantartott szabály.

A jogosultsági szintek

@auth(level)Mit jelent
PUBLICBárki, akár nem hitelesített is
USER_ANONHitelesített (akár anonim) felhasználó
USEREmail-megerősített, nem anonim felhasználó
USER_EMAIL_VERIFIEDCsak email-verifikált
NO_ACCESSCsak admin-credenciálok (server-side)

Finomabb feltételek

A szint mellett egy where kifejezést is hozzátehetsz, ami a JWT-ből kiolvasott adatokra hivatkozhat:
auth-examplesgraphql
# A user can only see their own orders
query MyOrders @auth(level: USER) {
  orders(where: { user: { uid: { eq_expr: "auth.uid" } } }) {
    id, total, createdAt
  }
}

# Only admin can delete a post (custom claim)
mutation DeletePost($id: UUID!)
  @auth(level: USER, expr: "auth.token.role == 'admin'") {
  post_delete(id: $id)
}
Az auth.uid a JWT subject (a felhasználó UID-je), az auth.token a teljes token tartalom, beleértve a custom claimeket (mint a role). Ez ugyanaz a mechanizmus, amit a Firestore Security Rules-ban használsz — csak itt nem külön fájlban van, hanem közvetlenül a művelet mellett.
Olvashatóság
A @auth direktíva előnye, hogy a query és a hozzá tartozó jogosultság egymás mellett van. Ha valaki olvassa a kódot, azonnal látja, hogy ez a query kinek elérhető — nem kell egy másik fájlban keresgélnie. Ez sokkal könnyebben karbantartható lehet, mint egy 500 soros firestore.rules fájl.
Mit tanulsz
  • type-safe-sdkKözéphaladó

08 — SDK-k

Generált típusbiztos SDK-k

Az SQL Connect egyik legjobb funkciója, hogy a kliens SDK-t magától generálja a sémából és a queryk-ből. Webre TypeScript-et, Androidra Kotlin-t, iOS-re Swift-et, Flutterre Dart-ot. Minden lekérdezés egy típusos függvény, amit egyenesen importálhatsz az appodban.

Hogy néz ki a generált kód?

webapp/src/App.tsxtypescript
import {
  getRecentPosts,
  createPost,
  type GetRecentPostsResponse,
} from '@my-app/dataconnect';

// Typed query — auto-completion, type-checking
const { data, error } = await getRecentPosts({ limit: 10 });

// data.posts has exactly the type the query returns —
// no <any>, no "I hope it looks like this" assumption
data.posts.forEach(post => {
  console.log(post.title, post.author.displayName);
});

// Mutation — also typed
await createPost({
  title: 'New article',
  content: '...',
  tags: ['firebase', 'sql'],
});
A generált SDK-ban minden query és mutation egy függvény, paraméterei típusosak, visszatérési értéke típusos. Az IDE auto-completionja működik, a TypeScript fordító ellenőrzi a hívásokat, és ha módosítod a sémát, a kliens kód is pirosra vált, ahol nem stimmel.

Mit ad ez a klasszikus REST API-hoz képest?

Egy klasszikus REST integrációban általában van egy:
  • Backend kód (Express, NestJS, Laravel...).
  • OpenAPI vagy Swagger spec, amit kézzel kell karbantartani.
  • Külön kliens SDK, amit vagy generálsz az OpenAPI-ból, vagy kézzel írsz.
  • Külön validáció backenden és frontenden.
Az SQL Connect-ben ez egyetlen séma- és query-fájllá zsugorodik. A backend kód nem létezik — az SQL Connect motorja értelmezi a queryket, és lefordítja Postgres SQL-re. A kliens SDK magától generálódik. A típusok mindig konzisztensek, mert egyetlen helyről származnak.

Frameworkenkénti integráció

A generált SDK mellé frameworkenkénti integrációk is jönnek:
  • React — TanStack Query alapú hook-ok minden queryhez (useGetRecentPosts).
  • Angular — RxJS Observable-ök, Signal-ok, vagy egyszerű Promise.
  • Flutter — natív Stream-ek a realtime feliratkozásokhoz.
  • iOS / Android — coroutines, async/await, vagy callback alapú API-k.
Mit tanulsz
  • sql-connectKözéphaladó

09 — Firestore vs. SQL Connect

Firestore vagy SQL Connect?

A Firestore és az SQL Connect nem helyettesíti egymást — két különböző problémára való. A választás nem stílus kérdése, hanem az adat természetén múlik. Itt a fő szempontok, amik segítenek dönteni.
SzempontFirestoreSQL Connect
AdatmodellNoSQL dokumentumRelációs (PostgreSQL)
Lekérdezés-erőKorlátozott (nincs join, korlátos OR)Teljes SQL erő (joinok, aggregációk, ablakfüggvények)
TranzakciókKorlátozottTeljes ACID
KlienselérésKözvetlen — Security Rules védCsak előre definiált műveletek — @auth véd
RealtimeKlasszikus erősségeÚj funkció (GA óta)
SkálázódásGyakorlatilag korlátlanCloud SQL skálázódás (vertikális, replikák)
Belépési pont (induló költség)$0 (Spark plan)~$9.37/hó (db-f1-micro)
Pricing modellMűveletek alapjánCloud SQL instance + operations
MigrációLock-in (export bonyolult)Standard PostgreSQL — könnyebb átköltözni

Mikor melyik?

Választás

Firestore vagy SQL Connect?

Firestore

Mobile-first appok, valós idejű kollaboráció, kis-közepes adatmennyiség, sok user, dokumentum-orientált adat (chat, jegyzetek, profilok). Ahol a séma rugalmas és gyorsan változik.

SQL Connect

Üzleti rendszerek bonyolult relációkkal, riportok, analitikai lekérdezések, pénzügyi adat erős konzisztenciával, klasszikus admin-felületek. Ahol az SQL ereje hiányzik a Firestore-ból.

A gyakorlatban: ha a Firestore-ban már rendszeresen denormalizálsz, és úgy érzed, hogy minden képernyőre 5 különböző trigger-Cloud-Function tartja karban az aggregátumokat — akkor SQL Connect a természetesebb választás. Ha viszont a séma rugalmas, az adat nagyrészt egyszerű (felhasználói profilok, dokumentumok, beállítások), és a valós idejű élmény fontos, akkor Firestore.
Mit tanulsz
  • sql-connectHaladó

10 — Hibrid

Hibrid — együtt használat

A Firestore és az SQL Connect nem zárja ki egymást — ugyanabban a Firebase projektben mindkettő ott lehet, és sok szempontból érdemes is így használni. Az egyik a rugalmas, gyorsan változó adatra, a másik a szerkezetes, relációs adatra.

Egy jellemző hibrid felosztás

Egy SaaS termékben például így nézhet ki a felosztás:
Adat típusaHol legyen
Felhasználói profilok, beállításokFirestore (kis adat, gyakran változó)
Chat üzenetek, presenceRealtime Database vagy Firestore
Jegyzetek, dokumentumok, sablonokFirestore (rugalmas séma)
Rendelések, számlák, tranzakciókSQL Connect (erős konzisztencia)
Termékkatalógus, készletSQL Connect (relációs, sok join)
Riportok, dashboardokSQL Connect (aggregációk)
Audit log, történeti rekordokSQL Connect (tartós, analizálható)

Az integráció

A két rendszer közötti kapcsolat jellemzően a felhasználói azonosítón keresztül megy. A Firebase Auth UID-je a Firestore users kollekciójában is, és az SQL Connect users táblájában is jelen van — egyik sem „mester", csak két nézet ugyanarra a felhasználóra.
Ha van olyan művelet, ami mindkét rendszert érinti (pl. egy rendelés létrejöttekor egy értesítés is mehet egy Firestore notifications kollekcióba), akkor erre Cloud Function jön — egy onCreate trigger az SQL Connect oldalon, ami létrehozza a Firestore-rekordot.
Konzisztencia
Két különböző adatbázis között nincs tranzakció. Ha a Cloud Function félúton elhasal, akkor a két rendszer szinkronja megbomlik. Ezért a hibrid megközelítésnél a kritikus adatot egyetlen rendszerben kell tartani — a másikat csak „nézetnek" használd, ami szinkronizációval frissül, és aminek hibája esetén utólag javítható.
Mit tanulsz
  • sql-connectKözéphaladó

11 — Pricing

Pricing — Cloud SQL költség és műveletek

Az SQL Connect két összetevőből áll: maga az SQL Connect szolgáltatás, és a mögötte futó Cloud SQL PostgreSQL instance. Mindkettőt külön számlázza a Google. Az induló költségek alacsonyak, de érdemes érteni a struktúrát, mielőtt indulsz.

SQL Connect szolgáltatás-díj

TételIngyenesFelette
Műveletek (queryk, mutationök)250 000 / hó$4.00 / 1 millió művelet
Hálózati kimenő forgalom10 GiB / hóGoogle Cloud Premium Tier díjszabás

Cloud SQL PostgreSQL költség

Itt a Cloud SQL standard díjszabása érvényes. Az SQL Connect alapértelmezett konfigurációja egy db-f1-micro instance:
  • 3 hónap ingyenes próba a GA-óta — ez lényegében Spark-szerű limitek nélkül.
  • Utána ~$9.37 / hó a legkisebb (db-f1-micro) instance-ért. Ez 600 MB RAM, 1 megosztott vCPU.
  • Felfelé skálázható tetszőleges méretű instance-ig — nagy alkalmazáshoz $50-500 / hó között mozog jellemzően.
Tényleges költség
Egy átlagos KKV-s SaaS-nál, ami napi 100-1000 felhasználót szolgál ki, az SQL Connect-szolgáltatás díjszabása legtöbbször 0 marad (250k művelet havi 8000 művelet napi forgalmat jelent), és a Cloud SQL adja a fő költséget. Egy db-g1-small instance (~$25/hó) bőven elég egy korai szakaszú SaaS-hez, és bármikor felfelé skálázható.

Hogy különbözik ez a Firestore-tól?

Pricing dimenzióFirestoreSQL Connect
Induló költség$0 (Spark)~$9.37/hó (Cloud SQL)
Skálázási karakterLineáris (per művelet)Lépcsős (instance-méret)
Olcsó alacsony forgalomnálIgenNem (kell az instance)
Olcsó nagy forgalomnálNem (sok művelet drága)Igen (nagyobb instance, lineáris hatás)

Tehát: kis vagy szezonális forgalmú appra a Firestore olcsóbb, mert nem kell mindig fizetni egy instance-ért. Nagy, állandóan magas terhelésű appra az SQL Connect olcsóbbá válik — egy 1 millió művelet/nap forgalom Firestore-ban súlyos összeg, SQL Connect-ben pedig egy közepes Cloud SQL instance kérdése.

Mit tanulsz
  • sql-connectKözéphaladó

12 — Konklúzió

Mikor érdemes választani?

Az SQL Connect a Firebase-ben volt nagy hiányzó láncszem — a relációs adat. Nem versengés a Firestore-ral, hanem kiegészítés. Aki üzleti rendszereket épít, az most már mindenből választhat: dokumentum-alapú, fa-alapú, vagy relációs adatmodell.
Az SQL Connect három területen kiemelkedő: relációs adatmodellek tisztán kezelhetők SQL erejével, típusbiztos kliens SDK generálódik magától (ami megspórolja a REST-OpenAPI-kliens generálás háromlépéses körhintáját), és a kliens csak előre definiált műveleteket futtathat, ami szigorúbb biztonsági modell, mint a Firestore Security Rules.
Ahol megfontolandó: kis projektnél a Cloud SQL instance fix költsége fáj — aki egy belső mini-app-ot ír 5 felhasználónak, annak a Firestore Spark-on jobban jár. Schema-flexibilitásnál a Firestore még mindig nyer — ha a séma minden héten változik, a Postgres-migrációk kezelése bonyolultabb. Tisztán mobile-first appoknál, ahol a valós idejű kollaboráció a fő funkció, a Firestore érettebb és szerteágazóbb.

Tervezési checklist SQL Connect indulás előtt

  • Az adatmodellem tényleg relációs (sok join, sok aggregáció), vagy csak megszokásból tervezem így?
  • Eldöntöttem, hogy strict mode-ban (SQL Connect vezet) vagy compatible mode-ban (Postgres vezet) dolgozom?
  • A queryket előre felírtam — minden képernyőhöz tudom, milyen lekérdezésre lesz szükség?
  • Mindegyik queryhez és mutationhöz hozzárendeltem a megfelelő @auth(level: ...) direktívát?
  • Cloud SQL régiója közel van a felhasználóimhoz (pl. europe-west1 EU-s usereknek)?
  • A séma migrációt CI-ből futtatom, és tesztkörnyezetben valós SQL-en kipróbálom, mielőtt élesíteném?
  • Költség-kerete van a projektnek a Cloud SQL instance-ra (legalább db-f1-micro a minimum)?
  • Ha hibrid (Firestore + SQL Connect): tisztán definiáltam, melyik adat hova kerül, és hogy szinkronizálódnak?
  • Vannak olyan komplex lekérdezések, amik native SQL-t igényelnek? Ha igen, ezeket külön kommenteltem és tesztelem?
  • A generált SDK CI-ben magától újra-generálódik a séma változása után, és committolódik a kliens repóba?

Az SQL Connect nem váltja le a Firestore-t — kiegészíti azt. A Firebase végre teljes platform: dokumentum, fa és relációs adatmodell, mind ugyanazon Auth és Hosting alatt.

A következő cikkben a Cloud Functions architektúrákat vesszük mélyebbre — hogyan írj olyan szerveroldali kódot, ami a Firebase ökoszisztémában jól skálázódik és nem fut bele a klasszikus serverless csapdákba. Ott visszatérünk arra is, hogy az SQL Connect mellett milyen szerepe maradt a Functions-nek, és hogy a kettő hogyan dolgozik együtt.
Vissza az elejére