Last Friday and Saturday, I attended Data Saturday Rheinland 2026 at Hochschule Bonn-Rhein-Sieg. The two-day event combined a full-day PostgreSQL pre-conference workshop with sessions on SQL Server performance, generative AI, data literacy and window functions.
What made the event particularly useful was the combination of technical content and direct conversations with speakers, DBAs, consultants and other data professionals.
I had also submitted sessions for Data Saturday Rheinland myself. Although I attended as a participant this time, I was prepared to step in at short notice when one of the scheduled speakers had to cancel.
In the end, the organisers found another replacement, but being available was important to me. Community events depend on people who are willing to contribute, whether through a planned session, an informal discussion or by helping when the original agenda can no longer be maintained.
That also changed my perspective on the event. I was not only there to consume content. I had prepared topics of my own, was ready to speak and paid close attention to how other speakers structured their sessions, explained technical details and interacted with the audience.
Eight hours of PostgreSQL for SQL Server DBAs
The event started on Friday with Grant Fritchey’s full-day pre-conference session:
What a SQL Server DBA Needs to Know About PostgreSQL
For someone who has spent many years working primarily with SQL Server, PostgreSQL is an interesting subject for several reasons.
More organisations are using multiple database platforms. Applications are no longer automatically built on one preferred relational database system, and SQL Server professionals increasingly encounter PostgreSQL in migrations, cloud environments or mixed technology stacks.
That does not mean that every SQL Server DBA needs to become a PostgreSQL specialist. It does mean that we should understand the main differences.
Administration concepts, configuration, indexing, execution plans, maintenance and troubleshooting may look familiar at first, but the underlying behaviour and operational assumptions are not always the same.
An eight-hour session provided enough time to move beyond a simple feature comparison. It allowed Grant to explain where SQL Server experience transfers well, where it can create false assumptions and which PostgreSQL concepts require a different mental model.
That distinction matters. Familiar terminology can sometimes be more dangerous than completely unfamiliar technology because it encourages us to assume that two systems behave in the same way.
Saturday at Data Saturday Rheinland 2026
Saturday offered several sessions that approached data platforms from very different directions.
GenAI and data literacy
Marco Nielinger presented:
GenAI for Data & Analytics: What’s Hot and What’s Not?
Generative AI is currently included in almost every technology discussion, but the practical value varies considerably between use cases. Sessions like this help separate capabilities that can already support real work from ideas that are still mainly demonstrations, experiments or marketing.
Oliver Engels and Katharina Ricken discussed:
Building Data Literacy in the Microsoft Data Platform Era
Technical platforms alone do not solve data problems. An organisation may have modern tools, centralised data and sophisticated reporting while users still struggle to interpret information correctly or make decisions from it.
Data literacy is therefore not a side topic. It influences whether investments in analytics and data platforms produce useful results outside the technical teams that build them.
Grant Fritchey returned with:
SQL Server performance and window functions
Query Performance Enhancements in SQL Server 2025
SQL Server 2025 introduces new options and changes that can affect how we analyse and improve query performance. For DBAs and consultants, the relevant question is not merely which features are new. We also need to understand when they apply, what problems they address and how they change existing troubleshooting practices.
New performance features can support diagnosis, but they do not replace the need to connect query behaviour, waits and infrastructure signals. I discussed that distinction in more detail in SQL Server Monitoring Is Not Diagnosis.
Thomas Hütter closed my personal agenda with:
Window Functions in SQL Server: Brush Up Your Skills
Window functions have been available in SQL Server for years, but they are still frequently underused or used without a clear understanding of their behaviour. Revisiting established functionality is often just as useful as learning about a new feature.
A better understanding of existing SQL capabilities can simplify queries, reduce unnecessary processing and make code easier to maintain.
The value is not limited to the sessions
The sessions were interesting, but events like Data Saturday Rheinland offer something that online training, documentation and recordings cannot fully reproduce.
The speakers are physically present.
When a detail is unclear, you can ask immediately. When a demonstration raises another question, you can discuss it directly with the person presenting it. Speakers can explain why they recommend a certain approach, where it has failed and which constraints are often missing from a simplified technical example.
That direct access changes the quality of the conversation.
The same applies to discussions between sessions.
Talking with other DBAs, consultants, service providers and platform specialists gives me a broader view of how other organisations work:
- Which problems are they currently seeing?
- How are they operating their SQL Server environments?
- Which tools and processes have worked for them?
- Where have technically reasonable approaches failed in practice?
- Why did they choose one solution instead of another?
These conversations do not always produce an immediate technical answer. Often, their value is in questioning assumptions.
A configuration or process may appear normal because it has been used in the same organisation for years. Meeting people from other environments provides a useful comparison. They may solve the same problem differently, face constraints you have never encountered or have already tested an approach you are only beginning to consider.
Community events remain relevant
Most technical information is available online. Documentation, conference recordings, blogs and training platforms make it possible to learn almost anything without travelling to an event.
But access to information is not the same as access to experience.
An in-person community event creates room for follow-up questions, disagreement, practical examples and conversations that were not planned as part of the official agenda.
Having submitted sessions myself and being ready to step in also reminded me that these events only work because people contribute their time, experience and willingness to help.
For me, that remains one of the strongest reasons to attend.
Data Saturday Rheinland 2026 offered strong speakers, relevant topics and plenty of opportunities to exchange experiences with people working on similar problems from different perspectives.
I returned with new technical input, a better understanding of several topics and, equally important, new questions to follow up on.
That is a good result from two days at a community event.
