Data is the new oil, and your database is the only way to extract it

Summary of Data is the new oil, and your database is the only way to extract it

by The Stack Overflow Podcast

40m•February 17, 2026
Listen to Episode

Overview of "Data is the new oil, and your database is the only way to extract it" (The Stack Overflow Podcast)

This episode features Sharish Thotha, Corporate VP of Azure Databases at Microsoft, in conversation with host Ryan Donovan. They survey Microsoft’s cloud database portfolio (SQL Server/Azure SQL, Cosmos DB/DocumentDB, MySQL, Postgres and the new HorizonDB), discuss architectural trade-offs between relational and NoSQL systems, share engineering details (indexing for JSON, cache strategies like RBPEX/continuous priming), and explore how AI and unified data platforms (Fabric) are shaping the future of databases. The episode includes practical guidance on performance, cost governance, multi-cloud considerations and developer experience.

Key topics discussed

  • Microsoft’s database portfolio: SQL Server (on-prem and Azure SQL), Cosmos DB, DocumentDB (Mongo API/open source), MySQL, Postgres, HorizonDB, and Fabric.
  • Differences and trade-offs: relational (ACID, rich queries) vs. NoSQL (elasticity, tunable consistency, schema flexibility).
  • Architecture patterns: disaggregated compute/storage, high availability, geo-distribution, read replicas.
  • Performance-techniques: in-memory OLTP history, RBPEX (secondary buffer/caching), continuous priming of secondaries, Hyperscale.
  • NoSQL internals: representing JSON as a tree, path-based keys, inverted indexes, bitmap compression, mapping to B-trees.
  • Postgres ecosystem: extensibility, PGVector, community momentum; Microsoft contributions and Azure Postgres offerings.
  • HorizonDB: Microsoft’s new high-scale Postgres offering (disaggregated, many read replicas, single-digit ms commits).
  • Cost governance and cloud economics: avoiding runaway costs via right-sizing, index/design choices, unified platforms (Fabric) and open data formats (Parquet).
  • AI and databases: RAG, vector indexing, pushing compute into the database, agentic interactions, AI-assisted admin tools (auto-indexing, intelligent query processing, copilots).
  • Multi-cloud and data portability: running databases across clouds and the importance of open formats and interoperability.

Main takeaways / actionable points

  • Pick the right database for the workload:
    • Use relational (Azure SQL/SQL Server) for mission-critical, ACID-heavy enterprise workloads.
    • Use Cosmos DB for user-facing, massive-scale, highly-available, schema-flexible apps (e.g., chat/retail scenarios).
    • Use Postgres when you want extensibility, open ecosystem integrations (and AI-friendly extensions like PGVector).
  • Architect for scale and cost:
    • Prefer decoupled compute and storage to independently scale and control costs.
    • Optimize data modeling and indexes; choose provisioned vs serverless models based on traffic patterns.
  • Use modern DB automation:
    • Leverage auto-indexing, intelligent query processing, and DB “copilots” to reduce manual tuning.
    • Employ caching strategies (RBPEX) and continuous priming to reduce the need for expensive all-in-memory deployments.
  • Make data portable and open:
    • Keep data in open formats (Parquet) to reduce vendor lock-in and simplify multi-cloud or analytics scenarios.
    • Consider unified data platforms (Microsoft Fabric) to avoid stitching many services together and to cut egress/format friction.
  • Prepare for AI-first patterns:
    • Expect vector search, RAG, semantic retrieval, and in-database agents to become standard capabilities.
    • Push some AI compute down to data where privacy/efficiency matter; use DB-native retrieval to augment LLM prompts.

Notable quotes & insights

  • "Postgres is the Linux of databases." — on community, extensibility and ecosystem momentum.
  • "We give you tunable consistency." — Cosmos DB supports different consistency models, not just eventual consistency.
  • Indexing JSON: think of JSON as a tree, use path-as-key + inverted index (document IDs as values), compress with bitmaps, map to B-tree structures.
  • "Decoupling compute and storage makes it easier for you to scale them independently and have cost-effective growth." — rationale behind Hyperscale/HorizonDB architectures.
  • Future emphasis: AI infusion, better developer UX (chat/query conversations), stronger distributed systems guarantees and ongoing focus on resiliency/security.

Technologies & products mentioned

  • Relational and enterprise:
    • SQL Server (on-prem and cloud), Azure SQL, SQL Server 2025 announcement.
    • Hyperscale features (decoupled compute/storage, RBPEX).
  • NoSQL and document:
    • Cosmos DB (multi-model, global distribution, high availability).
    • DocumentDB (Mongo API, open-source donation).
  • Postgres and related:
    • Azure Postgres (Flex—managed, community-compatible).
    • HorizonDB (MS’s new disaggregated, high-scale Postgres).
    • PGVector, PG-18/PG-19 (Postgres releases).
    • VS Code extension for Postgres management (developer tooling).
  • Platform & ecosystem:
    • Microsoft Fabric (unified data platform, Parquet format).
    • RAG (retrieval-augmented generation), vector indexing/search.
  • Concepts: RBPEX (secondary buffer), continuous priming, inverted index, bitmap compression.

Future outlook (next ~5 years — summarized)

  • Heavy AI integration: RAG, vector indexes, in-database agents and agent orchestration; more operations pushed into the database for privacy/efficiency.
  • Improved developer experience: conversational DB tooling, auto-tuning, copilots for DB admins/developers.
  • Stronger distributed guarantees: faster networks and hardware will enable tighter RPO/RTO and more geo-distributed application patterns.
  • Ongoing importance of openness and portability: open formats (Parquet) as a standard and multi-cloud flexibility.
  • Continued focus on resiliency and security (higher “nines” availability).

Recommendations for engineers evaluating DB choices

  • Map workload requirements first (consistency, query richness, scale, latency, schema evolution).
  • Model data and index patterns before lifting-and-shifting into cloud to avoid cost surprises.
  • Prefer managed offerings with disaggregated architecture if you expect rapid scale or heavy IO requirements.
  • For AI use-cases, evaluate Postgres (extensibility, vector extensions) and DB offerings with native vector/RAG support.
  • Keep data in open formats and plan for export/portability in case of future migration needs.

Resources & links mentioned

  • Microsoft Ignite Azure Databases announcements (search: "Azure Databases Ignite Announcements").
  • Sharish Thotha on LinkedIn: shirish.oneword (search on LinkedIn for his posts and summaries).
  • Stack Overflow episode show notes for links and the referenced Stack Overflow shout-out (Guffa — virtual method tables).

If you need this condensed further into a one-page quick-reference, or want a short bulleted checklist for migrating a specific workload (e.g., on-prem SQL Server → HorizonDB), I can produce that next.