Kako odabrati bazu podataka za modernu web aplikaciju

Odabir baze podataka nije natjecanje u popularnosti. To je arhitektonska odluka o obliku vaših podataka, dosljednosti koju vaše poslovanje zahtijeva, načinu na koji će se aplikacija skalirati i količini operativnog rada koju vaš tim može preuzeti. Baza podataka koju je lako mijenjati tijekom prvog tjedna može biti skupa za zamjenu nakon godinu dana migracija, integracija i produkcijskih podataka.

Započnite s modelom podataka

Za većinu novih web aplikacija u 2026. godini, upravljani PostgreSQL razumna je početna točka. Relacijske tablice, strani ključevi, povezivanja (JOIN) i transakcije odgovaraju uobičajenim proizvodima kao što su SaaS platforme, trgovine, sustavi za rezervacije i interni alati. PostgreSQL također ostavlja prostor za manje strogo relacijske podatke: jsonb je indeksabilan, a proširenja mogu dodati mogućnosti bez uvođenja druge usluge. PostgreSQL 18 dodaje značajke kao što su asinkroni I/O, uuidv7() i OAuth 2.0 autentifikacija, ali temelji—SQL, MVCC i dobro definirana ograničenja—važniji su razlog za njegov odabir. MySQL 8.4 LTS ostaje snažan izbor gdje su njegov ekosustav, opcije hostinga ili postojeća stručnost tima presudni.

Dokumentna baza podataka kao što je MongoDB bolji je izbor kada aplikacija prirodno čita i ažurira samodostatne agregate. Ugrađivanje povezanih podataka može učiniti operaciju nad jednim dokumentom atomskom i izbjeći JOIN-ove. Taj je model koristan za neke kataloge, profile i zapise temeljene na događajima, ali nije prečac za dizajn podataka: MongoDB dokumenti imaju ograničenje od 16 MiB, a transakcije nad više dokumenata postoje uz veću cijenu performansi. Ako naplata, zalihe ili dozvole ovise o odnosima između mnogih zapisa, relacijski je model obično lakši za razumijevanje.

SQLite zaslužuje više pozornosti nego što je dobiva. Ugrađen je, nema poslužitelja baze podataka za održavanje i dobro funkcionira za softver koji radi lokalno (local-first), desktop i mobilne aplikacije, prototipe te web stranice s malim do srednjim prometom. Vlastite smjernice SQLite-a opisuju oko 100.000 posjeta dnevno kao konzervativnu granicu za mnoge web stranice. Podržava mnogo istodobnih čitatelja, ali samo jednog pisca odjednom, pa klijent/poslužitelj baza podataka postaje prikladniji kada su operacije pisanja vrlo istodobne, kada je baza podataka odvojena od aplikacije ili kada podaci prerastu praktične granice jedne datoteke.

Uskladite s modelom implementacije

Poslužiteljske (serverless) i rubne (edge) aplikacije mijenjaju kompromise. Cloudflare D1 pruža SQLite semantiku s Workers API-jem, replikama za čitanje i Time Travel oporavkom za prethodnih 30 dana. Turso se temelji na distribuiranom libSQL-u i može pružiti ugrađene replike ili uzorke baze podataka po korisniku (tenant). Poslužiteljske PostgreSQL usluge kao što je Neon odvajaju računalne resurse od pohrane, nude ponašanje skaliranja do nule (scale-to-zero) i podržavaju “copy-on-write” grane koje su korisne za testiranje promjena sheme. Supabase dodaje autentifikaciju, pohranu, API-je, značajke u stvarnom vremenu, sigurnost na razini retka (RLS) i druge platformske usluge oko PostgreSQL-a. Te pogodnosti mogu skratiti vrijeme isporuke, ali ubrojite povezanost s platformom kao dio odluke.

Korisna matrica odlučivanja izgleda ovako:

• Relacijski SaaS, plaćanja, rezervacije ili zalihe: upravljani PostgreSQL.
• Postojeći PostgreSQL s opterećenjem čitanja: optimizacija upita, indeksi, povezivanje (connection pooling), zatim replike za čitanje prije shardinga.
• Izvanmrežna ili ugrađena aplikacija: SQLite.
• Mala rubna (edge) opterećenja s izoliranim podacima korisnika: D1 ili Turso.
• Duboko ugniježđeni agregati s ograničenim integritetom između zapisa: MongoDB, ili PostgreSQL jsonb ako je poželjna jedna baza podataka.

Operacije su dio odabira baze podataka

Upravljani hosting kupuje više od niza za povezivanje (connection string). Ovisno o usluzi, može uključivati ažuriranje zakrpa, visoku dostupnost, nadzor, pričuvne kopije i oporavak do određene točke u vremenu (PITR). Također dodaje trošak i ponašanje specifično za pružatelja usluga. Usporedite ukupni trošak, a ne samo oglašenu početnu razinu: računalni resursi, pohrana, I/O, zadržavanje pričuvnih kopija, visoka dostupnost i izlazni promet (egress) su važni. Cijene se često mijenjaju, stoga provjerite trenutne cijene prije obveze na plan.

Koji god mehanizam odaberete, rano definirajte operativni temelj. Pričuvne kopije nisu dokazane dok se oporavak ne testira. Arhiviranje PostgreSQL WAL-a plus osnovna pričuvna kopija podržava oporavak do određene točke u vremenu; pg_dump je samo logički izvoz, a ne zamjena za oporavak temeljen na WAL-u. Postavite cilj točke oporavka (koliko podataka možete izgubiti) i cilj vremena oporavka (koliko brzo se usluga mora vratiti), a zatim testirajte oboje.

Verzionirajte migracije u Gitu i uvježbajte ih na bazi podataka za testiranje (staging) ili izoliranoj grani. Za promjenu koja prekida kompatibilnost (breaking change), koristite pristup “expand-and-contract”: dodajte novi stupac ili tablicu, implementirajte kod koji može istodobno čitati ili pisati, obavite migraciju podataka, prebacite čitanja i tek tada uklonite staru strukturu. Time izbjegavate ovisnost implementacije o trenutnom dovršetku prepisivanja produkcijskih podataka.

Sigurnost i observabilnost trebaju biti jednako konkretni. Koristite TLS, uloge s najmanjim privilegijama, SCRAM autentifikaciju gdje je podržana i enkripciju u mirovanju. Za zajedničku PostgreSQL shemu, sigurnost na razini retka (RLS) može provoditi granice stanara (tenant boundaries) na razini baze podataka; na primjer:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_invoices ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Tretirajte tu politiku kao obranu u dubini, a ne kao dopuštenje za preskakanje autorizacije i testova u aplikaciji. Nadzirite veze, kašnjenje replikacije, pohranu, pogreške i spore upite. PostgreSQL-ovo proširenje pg_stat_statements praktična je početna točka jer prikazuje koje izjave troše najviše poziva i vremena izvršavanja.

Najbolji izbor stoga nije baza podataka s najotmjenijim popisom značajki. Odaberite najjednostavniji mehanizam koji ispravno predstavlja vaše odnose, pruža dosljednost koja vam je potrebna, odgovara vašem modelu implementacije i ima operativni put koji vaš tim može održati. Započnite s upravljanim PostgreSQL-om kada su podaci relacijski; odaberite SQLite kada je ugradnja prednost; odaberite dokumentnu ili rubnu (edge) bazu podataka samo kada su njezin model podataka i prednosti implementacije uistinu ključni za aplikaciju.

Izvori: PostgreSQL 18 release, PostgreSQL MVCC, PostgreSQL continuous archiving, PostgreSQL row security, SQLite appropriate uses, MongoDB transactions, Cloudflare D1, i Neon branching.