Serverless Bazy Danych 2024

Co to są serverless bazy danych i czym się różnią od tradycyjnych?

Serverless bazy danych: brak zarządzania serwerem. Skalowanie automatyczne do zera. Płać za użycie (requests/storage). Nie zawsze zero-cold-start. Kategorie: Serverless Postgres (Neon, Supabase, CockroachDB Serverless, Xata). Serverless MySQL (PlanetScale). Serverless SQLite (Turso/libSQL, Cloudflare D1). HTTP API databases (Turso, PlanetScale, Neon HTTP). Traditional vs Serverless: Traditional — zawsze running. Płacisz za czas. Szybkie queries. Serverless — scale to zero. Płacisz za użycie. Cold start (sekunda lub mniej). Serverless dla: serverless functions (Vercel, Cloudflare). Low traffic apps. Startups. Per-request billing. Nie dla: high-frequency real-time. Gaming leaderboards. Constant low-latency. Prisma + serverless: connection pooling wymagany. PgBouncer, Supabase Pooler, Neon pooling. Prisma Data Proxy (deprecated, teraz Prisma Accelerate). Neon: branching (jak Git dla bazy). Instant preview environments. Serverless Postgres kompatybilny. Drizzle + Neon: npx drizzle-kit push. Neon HTTP driver — brak stałego połączenia. @neondatabase/serverless. Cold start: Neon — instant (suspend/resume WAL). PlanetScale — fast startup. Turso — SQLite embedded, ultra-fast.

Neon i PlanetScale — serverless Postgres i MySQL?

Neon Serverless Postgres: branching jak Git. Każdy branch = osobna baza. Preview deployments z osobną bazą. Instant resume po uśpieniu. HTTP driver dla Edge: @neondatabase/serverless. import {neon} from '@neondatabase/serverless'. const sql = neon(process.env.DATABASE_URL). const rows = await sql('SELECT * FROM users WHERE id = $1', [id]). Suspend policy: auto-suspend po 5 min braku aktywności. Instant wake na request. Niskie koszty przy low traffic. Neon branching: neon branches create --name feature/login. Każdy PR = własna baza. Zero kopiowanie danych (Copy-on-Write). Merge branch po PR merge. Neon + Vercel integration: automatyczne branch per preview. Environment variables auto. Drizzle + Neon: drizzle(neon(connectionString)). PlanetScale: MySQL-kompatybilny. Vitess (YouTube scale). Branching for schema changes. Schema branching — nie data. Deploy requests (schema changes). Bezpieczne migracje bez downtime. Sharding — Vitess automatyczny. Prisma + PlanetScale: relationMode: 'prisma' (brak FK w Vitess). db push zamiast migrate. No schema migration history. PlanetScale Boost: query caching. In-memory cache per workspace. 100x szybsze powtarzające się queries. PlanetScale Scaler Pro: dla produkcji. Nie serverless — dedicated instances. CockroachDB Serverless: distributed SQL. Multi-region. Horizontal scale. PostgreSQL compatible. Dobry dla global apps.

Turso i Cloudflare D1 — SQLite na edge?

Turso (libSQL): SQLite na edge. libSQL — fork SQLite z HTTP support. Multi-tenancy — wiele baz. Embedded replicas — lokalna kopia w edge function. Ultra-low latency queries. @libsql/client: import {createClient} from '@libsql/client'. const client = createClient({url: process.env.TURSO_URL, authToken: process.env.TURSO_TOKEN}). await client.execute('SELECT * FROM users'). await client.batch(['INSERT...', 'UPDATE...']). Drizzle + Turso: drizzle(client). Embedded replicas: lokalna SQLite replika. Sync z Turso cloud. Zapytania z lokalnej kopii — zero network latency. Świetne dla read-heavy apps. Dla każdego użytkownika osobna baza (multi-tenant). Cloudflare D1: SQLite na Cloudflare Workers. env.DB.prepare('SELECT * FROM users').all(). Wazuma: baza w Worker — brak zewnętrznego połączenia. Alpha (2024): produktuje lepiej. Darmowy tier. Wink: D1 z Drizzle. WASM SQLite. Hrana: SQLite HTTP API. Ceny Turso: bezpłatny tier (3 DBs, 500MB). Starter: $6/mies. Scaler: $29/mies. Porównanie: Turso — standalone apps, multi-tenant, global. D1 — Cloudflare Workers integracja. Neon — serverless Postgres (PostgreSQL features). PlanetScale — MySQL-kompatybilny, Vitess scale. libSQL vs SQLite: libSQL = SQLite + replikacja + HTTP. Wstecznie kompatybilny. SQLite wasm: sql.js, wa-sqlite. SQLite w przeglądarce przez WASM. OPFS dla persistence.

ElectricSQL i local-first databases — offline-first architektura?

Local-first: dane przechowywane lokalnie. Sync gdy połączenie dostępne. Brak 'offline mode' jako afterthought — offline jest domyślny. Zawsze działa — nie zależy od sieci. ElectricSQL: local-first SQLite sync. SQLite w przeglądarce (OPFS) + PostgreSQL na serwerze. Automatyczna synchronizacja przez Electric. Shapes: reactive queries. const {results} = useShape({url: 'http://api/v1/shape/items'}). Real-time updates gdy dane się zmieniają. CRDT-free (electric robi merge). Instalacja: npm install electric-sql @electric-sql/react. Zasilane przez Postgres logical replication. Sync engine: Postgres -> Electric Sync Engine -> klienci. Instant local reads. Background sync. Konflikt resolution: Electric obsługuje przez server-wins lub CRDTs. PowerSync: alternatywa. SQLite + Supabase/Postgres. JavaScript SDK. React Native support. WatermelonDB: React Native offline-first. SQLite. Synchronizacja przez Sync Adapter. Dobry dla mobile. rxdb: reaktywna baza offline. CouchDB sync (PouchDB). IndexedDB storage. GraphQL offline: Apollo Client offline (InMemoryCache). Apollo persistence (AsyncStorage/IndexedDB). TanStack Query offline: networkMode: 'offlineFirst'. Queries run offline, sync on reconnect. Kiedy local-first: mobile apps. Field work (bez internetu). Real-time collaborative. High-performance reads. Nie dla: sensitive data (encryption required). Complex permissions (hard offline). Regulatory compliance (audit trails).

Connection pooling i database performance dla serverless?

Problem: serverless functions = wiele połączeń. Każda funkcja = nowe połączenie. Postgres max connections (zwykle 100). Cold start + connection = latency. PgBouncer: connection pooler. Transaction mode: share connections. Nie dla prepared statements. Supabase: wbudowany Supabase Pooler (port 6543). Transaction mode domyślny. IPv4 dla Vercel. Prisma Accelerate: Prisma Data Platform. Global connection pooling. Edge cache dla queries. npm install @prisma/extension-accelerate. prisma.$extends(withAccelerate()). findMany({cacheStrategy: {ttl: 60}}). Neon pooling: wbudowany w Neon. Serverless driver — HTTP zamiast TCP. @neondatabase/serverless — nie wymaga pooling. Drizzle ORM + serverless: import {drizzle} from 'drizzle-orm/neon-http'. Automatycznie HTTP requests. Brak persistent connection. Singletons w serverless: global._prisma — reuse connection. if (!global._prisma) { global._prisma = new PrismaClient() }. module.exports = global._prisma. Ale: nie pomaga przy cold start. Query optimization: EXPLAIN ANALYZE — plan zapytania. Indexes na WHERE, JOIN, ORDER BY. N+1 problem: include w Prisma. DataLoader — batch queries. Eager loading vs lazy loading. Connection timeout: pool_timeout w Prisma. connectTimeout w libpq. Retry logic przy connection error. Read replicas: Prisma readReplica extension. Neon read replicas. Skaluj read traffic osobno. Monitoring: Prisma Studio. pg_stat_statements — slow queries. Database dashboards (Neon, Turso, PlanetScale).

Wyślij zapytanie