Acum doi ani, o discuție pe LinkedIn dintre un DBA cu 20 de ani vechime și un analytics engineer la prima slujbă a devenit virală în comunitatea SQL românească. DBA-ul susținea că orice logică de business trebuie în stored procedures. Engineer-ul susținea că stored procedures sunt antipatice și că totul ar trebui scris în dbt. Discuția a strâns sute de comentarii și niciun consens.

Retrospectiv, după 2026 — cu maturizarea warehouse-urilor cloud, adopția generalizată dbt și extinderea Microsoft Fabric — cearta între stored procedures vs query ad-hoc nu s-a stins, dar s-a clarificat. Răspunsul nu mai e ideologic. E contextual. Acest articol e despre cum să alegi corect în 2026-2027, după ce ambele tabere au avut timp să-și consume argumentele.

Două lumi diferite de SQL

Înainte de a compara, e util să separăm două lumi distincte care folosesc SQL.

Prima lume — operational / transactional. Aici trăiesc aplicațiile business: ERP, CRM, e-commerce, sisteme custom. SQL-ul rulează pe MySQL, PostgreSQL, SQL Server, Oracle. Workload-ul: multe tranzacții scurte, citiri și scrieri concurente, latențe sub 100ms. Echipa: DBA-i și developeri backend.

A doua lume — analytical / data warehouse. Aici trăiesc dashboard-urile, rapoartele, analizele. SQL-ul rulează pe Snowflake, BigQuery, Fabric, Databricks. Workload-ul: query-uri mari pe miliarde de rânduri, agregări, joins complexe, latențe de secunde sau minute, fără concurency mare. Echipa: data analysts, analytics engineers, data scientists.

Tot ce urmează se aplică diferit în cele două lumi. O greșeală frecventă în 2026 era a importa intuiții dintr-o lume în cealaltă fără filtrare. Stored procedures sunt o decizie diferită într-un SAP Business One vs. într-un Snowflake.

Stored procedures: ce au fost și ce au devenit

Stored procedures sunt blocuri de cod SQL pre-compilate, stocate în bază de date, invocate prin nume cu parametri. Apărute în anii ’90 pe sisteme tip Sybase/SQL Server/Oracle, au fost mult timp soluția implicită pentru logică de business pe servere de date.

Argumentele lor istorice rămân parțial valabile:

• Performance prin pre-compilation. Plan-ul de execuție e cache-uit, nu se re-parsează la fiecare apel.
• Securitate — utilizatorii primesc EXECUTE pe procedure, nu SELECT/UPDATE pe tabele direct. Granularitate fină.
• Centralizare logică — un singur loc unde se schimbă regulile, nu zeci de aplicații care le duplică.
• Network traffic redus — un singur apel cu parametri, vs. transmiterea unui query lung din aplicație.

Pe partea operational/transactional, aceste argumente sunt încă serioase. Pentru o aplicație tip retail cu mii de tranzacții/secundă, stored procedure-urile bine scrise rămân alegerea corectă în multe cazuri.

Pe partea analytical, situația e diferită. Warehouse-urile cloud moderne (Snowflake, BigQuery, Fabric) au compilation foarte rapidă și cache-uri inteligente; câștigul de pre-compilation e marginal. Concurency-ul e scăzut, deci network round-trip-urile contează mai puțin. Și apar dezavantaje semnificative pe care le vom discuta.

Query-uri ad-hoc: explorarea zilnică a analystului

Prin „query-uri ad-hoc” înțelegem SQL scris la momentul interogării, de obicei dintr-un BI tool (Power BI, Tableau, Metabase), notebook (Jupyter), sau IDE (DataGrip, DBeaver). Logica nu e salvată în bază — e trimisă la fiecare execuție.

Caracteristici:

• Iterare rapidă. Modifici, rulezi, ajustezi, fără ciclu deploy.
• Versionabil în git dacă query-ul devine parte dintr-un model dbt sau dintr-un report.
• Vizibil pentru audit — query-ul complet apare în query history.
• Independent de DBA-i. Analyst-ul nu așteaptă să i se deploy-eze procedura.

În lumea analytical, e modul natural de lucru. Pentru un analist care explorează date la 9 dimineața, scrierea unei stored procedure ar fi un overhead inutil. Query-ul ad-hoc se modifică de zece ori până la rezultatul corect.

Punctul de cotitură: dbt și paradigma „models as code”

Apariția dbt și adopția lui masivă între 2020-2024 a schimbat fundamental conversația. dbt oferă o alternativă la stored procedures care păstrează beneficiile (logică centralizată, versionată, testată) fără dezavantajele lor (lock-in la baza de date, debugging dificil, control versioning prost).

Un dbt model e, esențial, un fișier SQL versionat în git, care produce un table sau o view în warehouse. dbt orchestrează crearea, dependencies-ul între modele, testele de calitate. Logica e codată, nu stocată într-un schema obiect.

Avantaje peste stored procedures clasice:

• Versionare în git, cu pull requests, code review, history clar.
• Modularitate prin macros și refs — DRY pe SQL.
• Testare automată (unique tests, not_null, accepted_values, custom tests).
• Documentație generată automat (dbt docs).
• Portabil între warehouse-uri (relative). Migrarea de la Snowflake la BigQuery e dureroasă cu stored procedures, mai ușoară cu dbt.

Pentru workload analytical în 2026-2027, dbt + warehouse cloud a devenit configurația implicită. Stored procedures pe Snowflake sau BigQuery încă funcționează tehnic, dar le folosesc tot mai puține echipe pentru logică analitică nouă.

Când stored procedures sunt încă alegerea corectă

Asta nu înseamnă că stored procedures sunt obsolete. Există scenarii unde rămân justificate în 2026-2027.

1. Sisteme transactional cu workload mare. ERP intern, e-commerce platform, financial trading. Volume mare, concurency mare, latențe sub 50ms. Stored procedures bine scrise pe SQL Server sau Oracle continuă să fie cea mai performantă opțiune.

2. Logică complexă cu multe iterații condiționale. Procesare batch care implică cursoare, condiții pe rânduri individuale, loops. SQL pur nu e potrivit; stored procedure cu T-SQL sau PL/SQL e natural.

3. Acțiuni cu efecte secundare. Generare numere de document, update de status pe mai multe tabele, side effects tranzacționale. dbt e read-only prin filozofie — pentru logică care scrie în baze operationale, stored procedures sunt potrivite.

4. Granularitate de securitate fină. Cazuri unde utilizatorii nu trebuie să vadă structura tabelelor, doar rezultatul unei proceduri specifice. Conformitate strictă (GDPR, PCI-DSS) poate cere această izolare.

5. Compatibilitate cu sisteme legacy. Aplicații existente care apelează stored procedures prin ODBC/JDBC. Migrarea la dbt înseamnă rescriere de aplicație — uneori e mai ieftin să menții ce funcționează.

Când query-uri ad-hoc / dbt câștigă clar

Scenariile inverse, unde stored procedures clasice sunt o alegere proastă în 2026-2027:

1. Logica analitică pe warehouse cloud. Snowflake, BigQuery, Fabric. Aici stored procedures nu mai oferă performance edge real, iar dezavantajele (versioning, testing, mentenanță) cântăresc greu. dbt e răspunsul.

2. Echipe distribuite care lucrează în paralel. Trei analytics engineers care fac modificări simultan. Pe stored procedures, este coșmar de git și deploy. Cu dbt, e flow natural.

3. Pipeline-uri cu dependențe complexe. 50+ modele care se calculează în ordine, cu refresh-uri parțiale. dbt rezolvă DAG-ul automat; cu stored procedures, e cod manual de orchestration.

4. Audit de calitate continuu. Vrei să verifici că orders_amount_total e mereu egal cu sum(line_amount). Cu dbt, e un test declarativ. Cu stored procedures, e cod custom de validare scris și menținut separat.

5. Echipe noi fără tradiție SQL adâncă. dbt + git e un pattern care se învață în 2-3 săptămâni. Stored procedures pe T-SQL sau PL/SQL avansat necesită ani de experiență pentru fluență.

Cazul hibrid: când amestecul are sens

În practică, multe companii rulează ambele paradigme. Tipic:

• OLTP system (ERP, CRM) — stored procedures pentru logică tranzacțională cheie.
• Pipeline ELT — date copiate din OLTP în warehouse zilnic.
• Warehouse — dbt models pentru transformări analitice și KPI calculation.
• BI tool — query-uri ad-hoc pe model-ele dbt, sau measures DAX direct.

În arhitectura asta, stored procedures rezolvă world-ul tranzacțional și dbt rezolvă world-ul analitic. Nu sunt în competiție — sunt în roluri diferite. Echipa de DBA întreține stored procedures pe sistemul operațional; echipa de analytics engineers întreține dbt models pe warehouse.

Tensiunea apare când o organizație vrea să forțeze o paradigmă unică. Tipic „totul în stored procedures” (DBA legacy împingând stilul lor de lucru) sau „totul în dbt” (analytics engineer entuziast, ignorând că OLTP-ul are nevoi diferite). Ambele extreme produc fricțiuni.

Performance: ce arată benchmark-urile reale

Pe partea de performance, mitul „stored procedures sunt rapide, query-urile ad-hoc sunt lente” merită demontat.

Pe warehouse-uri cloud moderne (Snowflake, BigQuery, Fabric) în 2026-2027:

• Compilation time pentru query analitice complex e sub 1 secundă. Pre-compilation prin stored procedure câștigă maximum 100-300ms.
• Query result caching e foarte eficient. Un query repetat cu același input servește din cache în milisecunde, indiferent dacă e ad-hoc sau în procedure.
• Optimizer-ul recunoaște patterns repetate și optimizează adaptiv.

Diferența de performance între un dbt model (creată ca table sau materialized view) și o stored procedure care face același job e neglijabilă. Diferența cu adevărat semnificativă vine din alegerea structurii de date (partitioning, clustering, indexes), nu din mecanismul de execuție.

Pe partea OLTP, lucrurile stau diferit. Pe SQL Server cu workload mare, plan caching prin stored procedures aduce câștiguri reale măsurabile. Aici intuiția DBA-ilor experimentați e corectă.

Observabilitate: cine câștigă

Un argument tehnic adesea ignorat. În 2026-2027, observabilitatea workload-urilor a devenit critică pentru cost control și debugging.

Pe warehouse-uri cloud, query history-ul arată complet ce a rulat. Cu query-uri ad-hoc (sau dbt models care produc SQL pur), poți vedea exact ce s-a executat, cât a durat, cât a costat. Identificarea unui query lent e directă.

Cu stored procedures, în history vezi „CALL my_procedure(parameters)” — fără SQL-ul intern. Pentru debugging, trebuie să faci profiling separat. Pe Snowflake și BigQuery sunt unelte pentru asta, dar adaugă pași.

Pe partea cost — pe warehouse-uri pay-per-use — saving-urile prin identificarea query-urilor scumpe sunt semnificative. Stored procedures fac asta mai dificil. dbt + warehouse native logs fac asta natural.

Securitatea: argumentul clasic, recontextualizat

Argumentul „stored procedures pentru securitate granulară” a fost mult timp puternic. În 2026-2027, e mai nuanțat.

Warehouse-urile cloud moderne au mecanisme native sofisticate:

• Row-level security aplicat la nivel de view sau policy. Granularitate per utilizator/rol.
• Column-level security — masking automat pe coloane sensibile.
• Dynamic data masking — utilizatori văd date redactate fără să existe procedure custom.
• Audit logging nativ pentru orice acces la date.

Toate astea fără să fie nevoie să scrii o stored procedure. Pe Snowflake, masking policies și row access policies acoperă majoritatea use case-urilor istorice de „use procedure pentru a controla cine vede ce”. Aceeași poveste pe BigQuery (column-level security, masking) și Fabric.

Stored procedures pentru securitate granulară rămân utile în OLTP-uri vechi unde aceste features native lipsesc. Pentru warehouse-uri cloud, sunt redundante.

Costurile reale

Comparație costuri pentru a menține logică similară:

Stored procedures pe SQL Server / Oracle on-prem:

• Licențe SQL Server Enterprise: $10k+/core/an.
• DBA dedicat: $40k-60k/an în România pentru profil senior.
• Mentenanță, backup, monitoring infrastructure.

dbt + Snowflake / Fabric:

• Warehouse cloud: $1.500-5.000/lună pentru mid-market.
• dbt Core gratuit, dbt Cloud Team $100-300/lună per echipă.
• Analytics engineer: $30k-50k/an în România pentru profil mid.

Pentru un workload analitic specific, costul total al stack-ului cloud + dbt e adesea sub jumătate din stack-ul stored procedure on-prem. Plus că scalează elastic — plătești ce folosești, nu plătești pentru capacity nealocat.

Asta a fost una dintre forțele care a împins migrarea masivă către dbt în 2024-2026. Nu doar argumente tehnice — și economice.

Recomandare practică pentru 2026-2027

Pentru o companie care decide arhitectura SQL pentru următoarele 3-5 ani, ghidul practic:

1. OLTP (ERP, CRM, app-uri tranzacționale): stored procedures rămân OK pentru logică complexă transactional. Folosește-le judicios — nu pentru orice query simplu, doar pentru cazurile unde aduc valoare.
2. Pipeline ELT (ingest în warehouse): scripts de ingest (Fivetran, Airbyte) sau native connectors. Stored procedures aici sunt rar justificate.
3. Warehouse / transformări analitice: dbt models. Stored procedures pe warehouse cloud — evită-le pentru greenfield. Migrează existente când ai resurse.
4. BI tools: query-uri ad-hoc generate de tool, peste model-ele dbt. Logic de business nu trebuie în BI tool — trebuie în dbt.
5. Reverse ETL (warehouse → operational): tool dedicat (Hightouch, Census) sau scripts. Stored procedures rar potrivite.

Această arhitectură separă responsabilitățile clar. DBA-ii întrețin OLTP, analytics engineers întrețin warehouse. Conflictele de paradigmă dispar pentru că fiecare echipă lucrează în mediul potrivit.

Privind înapoi la 2026

În 2026, conversația „stored procedures vs query” a intrat în maturitate. Comunitatea SQL românească a trecut prin ciclul tipic: hype pentru paradigma nouă, backlash de la susținătorii vechi, consens contextual.

Cei care insistau în 2024-2025 că „dbt e doar un fad” se mai văd ocazional pe LinkedIn, dar tot mai puțini. Pe partea opusă, entuziaștii care voiau să rescrie totul în dbt overnight au învățat că sistemele OLTP au logică legitimă în stored procedures.

În 2027, întrebarea „stored procedures sau query ad-hoc” nu mai e dogmatică. E o decizie de inginerie, luată pe context. Care e mediul (OLTP vs warehouse). Care e workload-ul (transactional vs analytical). Care e echipa (DBA-i sau analytics engineers). Care sunt cerințele non-funcționale (performance, audit, security).

Răspunsul corect e „depinde” — dar nu „depinde de preferință personală”. Depinde de criterii observabile și măsurabile. Asta e diferența între ingineria matură și flame wars pe forum-uri.

Întrebări frecvente

Sunt stored procedures depășite?

Depinde de lume. Pe partea operațională și tranzacțională argumentele lor istorice rămân serioase: performanță prin pre-compilare, securitate prin drept de EXECUTE în loc de SELECT sau UPDATE direct pe tabele, logică centralizată într-un singur loc și trafic de rețea redus. Pe partea analitică, situația e diferită.

De ce se preferă query-urile ad-hoc în analytics?

Pentru patru motive practice: iterare rapidă, fără ciclu de deploy; versionare în git dacă query-ul devine parte dintr-un model dbt sau dintr-un raport; vizibilitate pentru audit, prin query history; și independență față de DBA — analistul nu așteaptă să i se implementeze o procedură.

Ce a schimbat dbt în discuția asta?

A mutat-o spre paradigma „models as code”. Un model dbt e, în esență, un fișier SQL versionat în git care produce un tabel sau o vizualizare în warehouse — cu pull requests și code review, modularitate prin macros și refs, testare automată, documentație generată automat și portabilitate relativă între warehouse-uri.