Postgres: ce este, de ce este alegerea noastră implicită, cum o folosim

PostgreSQL (sau Postgres) este motorul relațional open-source pe care îl alegem implicit pentru aproape orice proiect cu nevoi de stocare structurată. Mai mult decât o bază de date, este un sistem cu peste 30 de ani de dezvoltare continuă, cu un compromis bun între performanță, corectitudine semantică, și ecosistem de extensii. Pentru un developer Java sau Node, alegerea implicită nu ar trebui să fie altceva.

Proiectul a apărut în 1986 la University of California, Berkeley, cu nume original „POSTGRES" (post-Ingres). În 1996 a primit suport SQL standard și numele actual. De atunci, ritmul de release e stabil: o versiune majoră pe an, cu suport pentru 5 ani. La crawlerra rulăm Postgres 16, eliberat în 2023 și suportat până în 2028.

Ce este Postgres mai exact?

Un sistem de gestiune a bazei de date relaționale, conform standardului SQL, cu garanții ACID complete (Atomicitate, Consistență, Izolare, Durabilitate). Stochează datele în tabele cu relații explicite între ele, le interogează cu SQL declarativ, și permite tranzacții care fie reușesc complet, fie eșuează complet.

Trei caracteristici care îl diferențiază de alte opțiuni open-source:

• Tipuri bogate și extensibile. Pe lângă VARCHAR / INTEGER / TIMESTAMPTZ, Postgres oferă nativ JSONB (JSON binar cu indexare), array-uri tipate (TEXT[], INTEGER[]), tipuri geografice (PostGIS), UUID, interval, range types, enum-uri.
• Index-uri performante și flexibile. B-tree, hash, GIN, GiST, BRIN, partial, expression-based; combinate, acoperă majoritatea pattern-urilor de query.
• MVCC (multi-version concurrency control). Read-erii nu blochează writer-ii și viceversa. La un moment dat, fiecare tranzacție vede o versiune coerentă a datelor, fără lock-uri explicite pentru read-uri.

Ce face Postgres special față de MySQL sau SQLite?

Pentru un proiect nou, alegerea implicită ar trebui să fie Postgres. Motivele se acumulează:

• Default-uri saner. Postgres respinge silent truncation, conversii implicite ciudate ("1abc"::integer), încărcături de date care nu se potrivesc. MySQL le acceptă tăcut, iar datele tale degenerează în timp. Postgres oprește execuția; afli imediat ce e greșit.
• JSONB cu indexare GIN. Pentru date semi-structurate (FAQ-uri, metadata, payload-uri webhook), JSONB e ca un document store imediat lângă datele relaționale. Indecsii GIN permit căutări în interiorul JSON-ului în timp logaritmic. Pe crawlerra-backend folosim JSONB pentru câmpul faq al articolelor (array de {question, answer}); nu e nevoie de Mongo sau Elasticsearch.
• Common Table Expressions și window functions. Query-uri complexe (ierarhii recursive, ranking pe partiții) devin lizibile. MySQL le-a adăugat târziu și incomplet.
• Extensii puternice. PostGIS (geo), TimescaleDB (time-series), pg_trgm (fuzzy matching), citus (sharding). Ecosystem-ul Postgres înlocuiește mai multe stacks de tipul „base de date + tool dedicat" cu o singură instanță.
• Performanță predictibilă. Pentru read-heavy fără concurrency masivă, MySQL câștigă cu câteva procente; pentru workload mixt cu writes și tranzacții complexe, Postgres este la fel sau mai bun.

SQLite este altă categorie: excelent pentru aplicații desktop, embedded sau single-file (CLI tools, mobile cache). Pentru un server multi-utilizator, nu e o alegere serioasă.

Care sunt capcanele frecvente?

• Vacuum tăcut care strânge dead tuples lent. Postgres marchează rândurile șterse sau actualizate ca „dead" și autovacuum-ul le curăță în background. Pe tabele cu update rate mare, autovacuum-ul default e prea conservator; ratele de bloat cresc și query-urile se încetinesc. Verifică pg_stat_user_tables periodic; pentru tabele hot, tune-ază autovacuum_vacuum_scale_factor.
• Connection pool over-sized. Postgres nu se descurcă bine cu sute de conexiuni active simultan. Folosește un pool (HikariCP în Java, pgbouncer extern) cu 10-30 conexiuni max. Un pool de 100 nu îți dă 100x throughput; te aduce mai aproape de OOM și de connection-storms.
• Index-uri pe coloane cu cardinalitate scăzută. Un index B-tree pe o coloană boolean este aproape inutil (B-tree-ul devine cât tabela). Pentru filtrare pe valori puține, folosește indici parțiali (WHERE active=true) sau lasă query planner-ul să facă seq scan.
• Tipuri TIMESTAMP fără timezone. Folosește mereu TIMESTAMPTZ. TIMESTAMP fără tz duce la confuzie subtilă între dev (Bucharest) și producție (UTC). Pe crawlerra am pățit-o: datele DTO-urilor noastre Jackson erau serializate fără sufix Z, iar Google flagua schema markup ca invalid¹.
• WAL nepăstrat sau backup-uri netestate. pg_dump rulat noaptea este un început, dar restaurarea trebuie testată. Un backup nerestaurat este o speranță, nu o strategie. Restaurează lunar pe un mediu de staging și măsoară timpul; restaurarea de 4 ore în timp de incident este o problemă pe care vrei să o știi în avans.

Cum folosim Postgres la crawlerra?

Backendul nostru rulează Postgres 16-alpine în Docker, bind-uit pe 127.0.0.1:5432 al VPS-ului de 1.8 GB. Volumul de date este montat pe disc local (/opt/crawlerra/data/postgres), nu pe Docker volume implicit, ca să avem control direct la upgrade-uri. Connection pool-ul HikariCP este setat la maximum 10 conexiuni; pentru cadența noastră (trafic moderat, două articole publicate pe săptămână), e mai mult decât suficient.

Schema este gestionată prin Liquibase, cu 14 changeset-uri active. JPA-ul (Hibernate) e setat cu ddl-auto: validate, ceea ce înseamnă că la fiecare boot Spring Boot verifică dacă entity-urile se potrivesc cu schema; orice nealiniere blochează startup-ul, ceea ce e mai bun decât o coloană tăcut nealiniată descoperită în producție.

Pentru tipuri non-banale: TEXT[] pentru câmpurile tags și related_slugs ale articolelor, accesate prin @JdbcTypeCode(SqlTypes.ARRAY); JSONB pentru câmpul faq (array de obiecte), accesat prin @JdbcTypeCode(SqlTypes.JSON); TIMESTAMPTZ pentru toate datele, serializate cu Jackson în UTC explicit (spring.jackson.time-zone=UTC). Tabela refresh_token pentru JWT-uri are 80k de rânduri în vârf de utilizare, accesate cu indici dedicați; query planner-ul rezolvă lookup-urile sub 1ms.

Cum verifici că totul merge corect?

Patru verificări lunare care detectează 90% din problemele Postgres înainte să fie incidente. Tabel bloat: rulează VACUUM ANALYZE manual și uită-te în pg_stat_user_tables la n_dead_tup. Tabele cu raport dead/live peste 0,2 trebuie tune-uite sau le rulezi VACUUM mai des.

Query slow log: setează log_min_duration_statement = 500 (ms) și citește log-urile săptămânal. Query-urile care depășesc 500ms sunt candidate la index nou sau la rewrite.

Backup restore drill: o dată pe lună, restaurează un dump pe un mediu de staging. Măsoară timpul. Documentează procedura într-un runbook. Un backup nerestaurat este iluzie, nu siguranță.

Connection saturation: prin stack-ul de observabilitate, trimite o alertă când pool-ul de conexiuni atinge 80% pentru mai mult de 5 minute. Asta înseamnă fie o aplicație care nu-și închide conexiunile, fie un trafic care scalează peste pool-ul setat; ambele cer atenție înainte să producă outage. Impactul direct pe SLA este real: o conexiune blocată înseamnă cereri respinse cu 503. Despre principiul „măsurăm tot" care ne face să verificăm aceste metrici săptămânal, vezi articolul nostru editorial.

1. Bug-ul ISO 8601 fără timezone a apărut în primele commits Phase 2A, detectat în triple-check, rezolvat prin migrare la OffsetDateTime + spring.jpa.properties.hibernate.jdbc.time_zone=UTC. [crawlerra.timezone_fix]