SQL Server, PostgreSQL and the Future

This is just a quick note to talk about the future, mine, yours and this blog.

First, I’m not abandoning SQL Server.

I’m actively working on a revision of the query performance tuning book (something I should be working on instead of writing this post). SQL Server is my first, and best, database love. We’re not going anywhere, SQL Server and I. You can expect more posts on SQL Server, query tuning, execution plans, DevOps, community, #sqlfamily, and everything I’ve blogged about for the last, ooh, 14 years next month.

Second, our family is growing.

Just like when a family brings home a new baby, well, I’m adding another database. It doesn’t mean I don’t love my first database. I still do. We’re just going to ALSO be talking about PostgreSQL.

I don’t know about your job, well, actually, I may. Surveys bear this out, more and more of us are supporting multiple data platforms. One of the single fastest growing relational platforms is PostgreSQL. It’s really cool from a technical standpoint. It has a danged active community. Frankly, I’ve been enjoying dabbling in it for the last two years. In fact, I’ve gotten serious and started writing a number of articles for Simple-Talk, with several more on the way.

That’s the plan. I just thought I’d share it with you. Feedback, questions, comments, as always, encouraged and welcomed.

Off to work on Chapter 12, Index Fragmentation.

6 thoughts on “SQL Server, PostgreSQL and the Future

  • Marc Bacon

    Been down the road of multiple databases. My first love will always be Oracle but I found my adventure in MS SQL Server to be exciting as well. Enjoy your adventure. I am too close to retirement to dabble in PostgresSQL or I think it would be my third. Actually my 4th. I did a little with DB2 and that was not interesting.

  • Dave Wentzel

    I think the best db pros understand at least 2 database managers and bonus points if you know a little NoSQL. Just being a SQL Server expert means that you only understand one way of thinking. When I first became an OCP in the late 90s I struggled keeping both ora and sql server concepts in my brain simultaneously. For decades there were flame wars about the fact that oracle doesn’t have “clustered indexes” and how can it perform without them…vs…oracle don’t need no “sorted data” structures like CIs to perform. It turns out 2 things can actually be true at the same time. But you _really_ need to understand how your chosen db manager works. Another example…I, like many dbas in the late 1990s, worried about table fragmentation and I had a job on every server to do dbcc dbreindex. When I learned Oracle I started to think about how sql server was storing data on pages and realized that in many/most cases the dbreindex command was doing more harm than good. Nowadays I think most sql server dbas know that fragmentation is a function of design…but at the time when I would speak on that topic it was considered heresy.

    I’ll say this…I’ve written two software packages for different ISVs where I could swap out the rdbms backend so we could sell the products to shops that refused to buy a MSFT or Oracle solution. Both supported sql server, oracle, postgres, and mysql. The ones that were the easiest for our team to support, required the least administration effort, easiest to code against, and performed the best without tuning (ie, all of the non-functional requirements) were, in order of best to worst: postgres, sql server, mysql…and bringing up the rear….way way back…was Oracle. PL/SQL is just horrendous.

    Just my anecdotal 2 cents.

Please let me know what you think about this article or any questions:

This site uses Akismet to reduce spam. Learn how your comment data is processed.