Microsoft’s SQL Server blog previewed the themes on August 13: SQL Server 2025 performance and vector search, Hyperscale for larger cloud workloads, and developer tooling around SQL Server Management Studio, Visual Studio Code, GitHub Copilot, and the emerging Database Hub experience. The independent conference program published by organizer ESPC corroborates the date, location at Barcelona’s CCIB convention center, and a schedule of more than 120 sessions. It also supplies the detail missing from Microsoft’s announcement: the SQL/Fabric overlap is already being expressed in core talks, specialist sessions, and paid tutorials rather than a single product keynote.
For IT teams, the distinction matters. This is a training and roadmap event, not a release notice. SQL Server 2025’s AI database features exist, but several of the most consequential vector-search capabilities remain preview features. Organizations should use the conference to validate deployment choices and operational limits—not assume that every session topic is a production-ready Microsoft commitment.
SQLCon Europe becomes part of Microsoft’s Fabric push
The Barcelona event is billed as the European Microsoft Fabric and SQL Community Conference, often shortened to FabCon Europe and SQLCon Europe. According to ESPC, the conference runs four days, although September 28 is structured around tutorials and a sold-out partner day while the main conference content follows across the subsequent days.
That format explains Microsoft’s emphasis on a single registration. Rather than positioning Fabric as an analytics destination separate from the operational databases that run line-of-business systems, Microsoft is using the event to connect SQL Server, Azure SQL, SQL databases in Fabric, OneLake, governance, and AI development. The published program labels its major SQL track “Databases in Fabric SQL Server & Azure SQL,” a naming choice that signals where Microsoft wants the conversation to go.
A scheduled “CORENOTE: The Roadmap for Microsoft SQL: Ground to Cloud to Fabric” session, with Microsoft speakers Priya Sathy, Bob Ward, and Anna Hoffman, is the clearest expression of that direction. It puts traditional on-premises SQL Server, Azure-hosted SQL services, and Fabric in the same roadmap frame.
That does not mean those products have become interchangeable. SQL Server remains the platform for organizations that need local control, predictable infrastructure ownership, or disconnected and regulated deployments. Azure SQL Database offers managed service operations, while Fabric is built around a broader analytics and data-platform model. The conference may help teams understand the integration points, but it cannot erase the different operational, licensing, networking, and data-residency consequences of choosing each platform.
SQL Server 2025 vector search is real, but its index path is still preview
The SQL Server 2025 portion of Microsoft’s announcement rests on actual, documented database-engine capabilities. Microsoft Learn lists a native vector data type, vector functions, external model objects, GitHub Copilot integration in SQL Server Management Studio, change-event streaming, and performance changes including batch-mode optimizations for selected built-in functions.
For developers building retrieval-augmented generation applications, the relevant change is the ability to keep embeddings beside relational data and query semantic similarity from SQL rather than immediately adding a separate vector database. Microsoft’s Entity Framework Core documentation says vector support arrived in EF Core 10.0 and works with SQL Server 2025 and later, making the feature especially relevant to .NET application teams that want strongly typed access to vector columns.
But the product documentation introduces a substantial constraint that Microsoft’s conference promotion does not spell out: approximate vector indexes and the VECTOR_SEARCH capability are still identified as preview in SQL Server 2025. Microsoft requires the PREVIEW_FEATURES database-scoped configuration for the preview path, and its documentation explicitly says the feature is subject to change.
That means a session on vector search should be useful for architecture planning and proof-of-concept work, but it is not by itself a reason to convert a production semantic-search workload. Exact vector searches can be appropriate for constrained result sets; Microsoft’s guidance recommends them when the candidate set is below roughly 50,000 vectors. Approximate nearest-neighbor indexes improve scale, but introduce the ordinary recall-versus-latency tradeoff of approximate search—and, in SQL Server 2025, the additional reality of preview status.
Teams attending SQLCon should ask speakers for the production support boundary in plain terms: which SQL Server 2025 builds are covered, what backup and availability behavior applies to vector indexes, how index maintenance affects write-heavy tables, and when Microsoft expects the preview configuration requirement to disappear. Those answers are more operationally valuable than another generic AI demo.
Azure SQL Hyperscale solves scale differently from a larger VM
Azure SQL Database Hyperscale is the second major platform theme. Microsoft describes Hyperscale as an Azure SQL Database tier whose storage and compute can scale independently. Current documentation says storage automatically grows from 10 GB up to 128 TB, while the architecture supports rapid compute changes without moving the data and can provide up to 30 named read-scale replicas.
Those are meaningful design differences from simply moving an existing SQL Server workload to a larger virtual machine. Hyperscale is aimed at databases where data growth, read fan-out, recovery objectives, or change volume make conventional single-node assumptions awkward. Microsoft also emphasizes snapshot-based backups and faster restores or copies, which can materially change the operational model for large databases.
“Grow without limits,” however, is conference language, not a literal technical guarantee. Hyperscale has documented limits, pricing dimensions, regional availability considerations, and workload-specific behavior. Storage may scale automatically, but operations teams still need to monitor allocation, ingestion pressure, log throughput, replica cost, query routing, and the behavior of dependent applications during compute changes.
The most useful Hyperscale sessions will therefore be the ones that show migration and failure scenarios, rather than only capacity claims. Attendees should look for concrete guidance on converting existing Azure SQL databases, reporting workload placement on named replicas, disaster recovery topology, and cost controls for databases whose data volumes grow faster than their business case.
Database Hub is a management promise that needs implementation detail
Microsoft’s announcement also promotes Database Hub as a place to “explore, observe, govern, and optimize” a database estate without changing the way each service is deployed. The concept addresses a genuine administrative problem: most enterprises run a mix of SQL Server instances, Azure SQL services, developer-owned databases, analytics platforms, and unevenly governed credentials and monitoring systems.
The language is promising, but the announcement does not say which database services are available in Database Hub today, whether it requires Fabric capacity, what permissions model it uses, or whether it can replace any existing administration tooling. Those omissions are important. Central visibility is useful; central authority can have very different compliance, segregation-of-duties, and audit implications.
The conference agenda suggests the management story is moving toward automation and agents. One scheduled session is titled “Database Agents: A New Way to Manage Databases in Fabric,” while another Microsoft-led session, “Data Productivity Tour: Query, Deploy, Optimize,” is aimed at DBAs, developers, architects, and IT professionals. The program confirms the direction, but it does not establish general availability, supported scope, or production governance standards for autonomous database operations.
Administrators should be especially careful not to interpret “AI-powered productivity” as permission to loosen review controls. GitHub Copilot, SSMS integration, Visual Studio Code extensions, and automation can reduce repetitive work, but generated T-SQL and deployment artifacts still need code review, test environments, least-privilege credentials, and rollback plans. Faster generation is not validation.
The program is broad enough to reward focused attendance
The event’s breadth is also its risk. The published agenda ranges from SQL synchronization and Azure SQL sessions to Fabric governance, lakehouse migration, Power BI, OneLake, data agents, and real-time intelligence. A DBA expecting four days of SQL Server engine internals could leave with a different experience than a developer looking for AI application architecture unless both build a targeted schedule.
ESPC lists a three-day conference ticket at €1,295 plus VAT and a four-day tutorial package at €1,495 plus VAT; the event’s partner-day allocation is already sold out. Those prices make a deliberate plan more important than treating the event as a general technology excursion.
For SQL Server teams, a sensible agenda would combine the Microsoft SQL roadmap session with vector-search technical content, Azure SQL Hyperscale architecture, deployment and observability talks, and at least one Fabric governance session. The benefit of co-location is not that every organization should move to Fabric. It is that SQL owners can compare the operational boundary between their systems of record and the analytics, AI, and agent-driven workloads now being built around them.
Barcelona will be the first European combined SQL and Fabric community conference, and Microsoft is clearly using it to make the “ground to cloud to Fabric” story tangible. The work for attendees is to separate what is shipping and supportable now—such as SQL Server 2025’s core vector data capabilities and Azure SQL Hyperscale—from previews, roadmap language, and management promises that still need hard answers before they enter a production change plan.