Press "Enter" to skip to content

Day: April 9, 2026

Comparing Schemas between PostgreSQL and Oracle

Published 2026-04-09 by Kevin Feasel

Laurenz Albe makes a comparison:

Recently, somebody asked me for a reference to a blog or other resource that describes how schemas work differently in Oracle. I didn’t have such a reference, so I’m writing this article. But rather than just describing Oracle schemas to a reader who knows PostgreSQL, I’ll try to present the topic in a way that helps Oracle users understand schemas in PostgreSQL as well. Since I already wrote about the difference between database transactions in Oracle and PostgreSQL, perhaps this can turn into a series!

Click through for the comparison. As far as SQL Server, here’s my off-the-cuff take:

  • Users and schemas — SQL Server follows the same model PostgreSQL does.
  • Schemas as namespaces — SQL Server follows roughly the same model Oracle does.
  • Schemas and object ownership — Different from the two, based on my reading. Objects are owned by the security principal that owns the schema. This is closer to the Oracle model but isn’t quite the same.
  • Schemas and privileges –Because of how object ownership works, there’s more flexibility to the SQL Server model, but also more complexity. In practice, it’s closer to the way PostgreSQL works.
  • Default schema — Different from the two. With one-part naming, SQL Server will first try the user’s default schema. If the object is not there, it checks dbo. That check, by the way, takes a small amount of time but can add up if you’re talking hundreds of thousands of transactions per second. Just ensuring you have consistent two-part naming can be a marked performance improvement on extremely busy servers.
  • System schemas — The sys schema includes system tables and Dynamic Management Views, and INFORMATION_SCHEMA provides the types of information the ANSI SQL standard requires.
Leave a Comment

The Death of SQL Server, Yet Again

Published 2026-04-09 by Kevin Feasel

Rebecca Lewis states that rumors of SQL Server’s demise have been greatly exaggerated:

LinkedIn is doing that thing again. ‘Is SQL Server Dead?’ posts are getting traction, the comment sections are lit, and I’m sure a lot of managers out there are forwarding one of them to a DBA with a question mark and no context. It happens every few years. NoSQL was going to kill it. The cloud was going to kill it. Now it’s AI and Fabric. I’ve been doing this for 28 years. Let me save you some time.

No. SQL Server is not dead or even dying. But something is changing — and we need to understand what.

Read on for Rebecca’s take. At the very least, I strongly agree with the general thrust of her argument. And, of course, I would be remiss if I didn’t mention Feasel’s Law here.

What makes this tricky is that there’s definitely more impetus from Microsoft to get people in Azure and using SQL Server-derived products up there. And the stability of the product has definitely taken a hit in the past couple of versions, something I chalk up to the organization removing QA teams back in about 2018. I do think the biggest competition for SQL Server is open-source relational databases, particularly PostgreSQL. At the same time, it’s not just a matter of “Let’s take a weekend and replace database management systems.” For that reason (among others), I do expect to see SQL Server around for quite a while.

And do check out Andy Yun’s comment. It links to a paper I’ve had on my to-read list that a Shop Talk viewer gave me while I was ranting on a somewhat similar topic.

Leave a Comment

pg_prewarm and a Bug in PostgreSQL 16.8

Published 2026-04-09 by Kevin Feasel

Warda Bibi explains an issue:

Recently, we encountered a production incident where PostgreSQL 16.8 became unstable, preventing the application from establishing database connections. The same behavior was independently reproduced in a separate test environment, ruling out infrastructure and configuration issues. Further investigation identified the pg_prewarm extension as the source of the problem.

This blog post breaks down the failure, the underlying constraint, why it manifests only under specific configurations, and the corresponding short-term mitigation and long-term fix.

Click through for those details. The bug is no longer an issue as of PostgreSQL 16.10.

Leave a Comment

Performing a GROUPBY in Excel

Published 2026-04-09 by Kevin Feasel

Ben Richardson explains a DAX function:

If you’ve ever built a summary table in Excel by writing five separate SUMIFS formulas – one for each region, product, or department – you’ll appreciate what GROUPBY does.

It collapses all of that into a single formula that updates automatically, sorts itself, and can even filter out rows you don’t care about.

Introduced to Microsoft 365 in late 2024, GROUPBY is one of the most practically useful additions Excel has had in years.

But it also comes with real limitations that most people gloss over.

Read on to learn more about the capability and one big catch.

Leave a Comment

Optional SUBSTRING() Length in SQL Server 2025

Published 2026-04-09 by Kevin Feasel

Louis Davidson points out a neat update:

Sometimes along comes a feature that seems so obvious, so natural, that you wonder why it took so long for Microsoft to implement it. One of those features in SQL Server 2005 is the optional length parameter in the SUBSTRING function. It has long been one of those questions when you wrote a SUBSTRING expression when you wanted to go from the Nth character to the end of the string, how many characters do you want? And for the most part, it didn’t really matter.

But sometimes it did (especially when dealing with nvarchar(max) data.

I learned about this when putting together an update to my Teaching Old Dogs New Tricks presentation. This capability is pretty nifty and something I wish I had a while ago.

Leave a Comment

The Scope of ##MS_DatabaseManager##’s Exposure

Published 2026-04-09 by Kevin Feasel

Andreas Wolter expands upon a prior post:

In my previous post (SQL Server Privilege Escalation via DatabaseManager-role: Newly discovered Attack Paths Explained), I showed how a privilege escalation can be achieved by modifying a stored procedure in msdb, based on research shared by Emad Al-Mousa.

When I looked into this more closely, it became clear pretty quickly:
It is not just about a few specific procedures.

Mind you, Andreas is not some kind of shrinking violet, and he was involved in the creation of this role in the first place. There are approximately zero people outside of Microsoft (and the number inside I could probably count on one hand) I would trust more to understand the nature and scope of this issue. This is definitely worth reading.

Leave a Comment