For years, data centers in the Microsoft-heavy DACH market ran on standard relational databases without operational strain. As AI workloads scale into production, those systems are being asked to handle document storage, embedding, and retrieval work they were not built for, and Postgres has become the default answer for the gap MSSQL cannot fill. Enterprise architects now spend most of their evaluation cycles on the operational thresholds where standard Postgres reaches its limits, and where a purpose-built alternative becomes worth the switching cost.
Florian Zeba, Principal Enterprise Architect Data & AI at ORBIS Austria, works this exact threshold daily, evaluating when standard Postgres holds and when it doesn't. His background spans law, AI, and computer science, and he brings years of consulting experience from PwC Austria to the executive-level architecture conversations where budget and technical fit both drive the decision. The discipline Zeba applies is mapping technical constraints directly to business realities.
"For PoC and MVP use cases, Postgres is a viable option in 90% of cases, and it's actively chosen, especially for any AI-related project," says Zeba. Across much of the enterprise AI market, there is a gap between ambition and infrastructure. The rapid popularity of generative AI led to rushed rollouts that left many companies working through the foundational challenges of adoption. Because so many organizations skipped basic data preparation, only a fraction of organizations currently possess AI-ready data. Architects are now deploying dedicated data platforms to retroactively build that foundation and bridge the gap between proof-of-concept and production.
Many DACH organizations handling AI workloads run a hybrid cloud strategy that keeps legacy systems in place. Under a people-first approach, the team's operational comfort with the existing stack becomes an input to the architecture decision. MSSQL runs underneath that pattern for many DACH enterprises, and Zeba is clear that the presence of AI workloads does not change that. "MSSQL is very good at what it does best, which is tabular, read-optimized, enterprise-level data warehousing," he explains. "New projects try to connect to existing MSSQL infrastructure instead of replacing it, so there is no directly forced migration."
The rise of Postgres for AI workloads inside DACH environments has also been shaped by physical factors independent of the software itself. Traditional server hardware shortages pushed organizations toward alternative deployment environments, and that pressure fueled a move back to Postgres, which already offered enterprise-grade pooling and queuing capabilities alongside its open-source licensing. "Other factors like hardware shortages also entered the equation," Zeba observes. "Companies began to switch from classical AMD or NVIDIA hardware to Mac Mini or Studio setups for on prem AI workloads."
Standard Postgres paired with pgvector handles the majority of early-stage AI workloads without stress, and the operational envelope only becomes a factor once specific technical thresholds are reached. Beyond a certain scale, the HNSW index that powers pgvector's similarity search moves out of memory, and query latency begins to degrade at the point where agentic workloads with tight latency budgets start to feel the impact. "pgvector on standard Postgres handles up to 5–10M vectors with sub-20ms p99 reliably," Zeba notes. "Beyond that, the HNSW index outgrows RAM and latency degrades sharply, hitting 68ms p99 at 10M vectors under 100 concurrent clients versus sub-10ms for DiskANN-native systems."
Database latencies and pgvector benchmarks lose relevance if the team maintaining the stack doesn't have the expertise to run it, if the existing infrastructure cannot accommodate it, or if the budget cannot support the switching cost. On top of that, data quality remains the most common failure point when organizations try to build AI on existing infrastructure, which is why the organizations reporting the highest AI success rates are those investing heavily in foundational data and analytics before writing a single line of AI code. What the architect is optimizing for is a system that delivers a clearly defined business outcome, and the technical choices work backward from that starting point.
The upside of running that framework in 2026 is that database choice has become significantly more reversible than it used to be. As companies move from MVP to production systems and integrate autonomous infrastructure into the stack, the same agentic engineering tooling that generates the workloads also provides the migration paths between databases when scale demands a change. Single-engine databases with tight latency budgets can now be evaluated on their operational fit at a given moment rather than as permanent architectural commitments. "Database choice is normally not a make-or-break decision because a switch to another storage solution can be handled more easily today," Zeba concludes. "Rewriting queries from T-SQL to Postgres-flavored SQL can now be done in days instead of weeks using agentic engineering."
