A Fine Slice Of SQL Server
Ryan Lambert rounds up the latest PGSQL Phriday:
Thank you everyone who contributed to PgSQL Phriday #005! This month’s topic: “Is your data relational?” If I missed any contributions, or if new ones are published, let me know and I’ll try to update this post. These snippets are in a somewhat random order, loosely threaded together by sub-topic.
Click through for the contributions.
Comments closedRyan Lambert thinks about software development:
Question: Do you store your SQL code in GitHub (or other source control, e.g. GitLab)?
Yes! All mission critical SQL I am involved with is saved in a Git repo, either public or private depending on the project. The use of source control for mission critical code (SQL, Python, etc.) is non-negotiable. A good portion of my “not trivial” code is also stored in source control, with my trend leaning towards more code in source control. The trivial code isn’t worth the effort of putting it into source control or the bloat it creates in those projects.
Read on for more.
Comments closedRyan Booz thinks about Database DevOps:
At the core, the biggest problem we needed to solve was making our database change process visible to the whole team. We had to modify our processes and the expectations we had of individual people within the team to deliver better, more consistent value at the data layer.
The tools we chose for our circumstances don’t apply completely to PostgreSQL because they were SQL Server specific. But the process and benefits of building a “database as code” mindset within the team accelerated our velocity and quality. And Joe didn’t have the weight of the world on his shoulders.
Ryan includes links to additional resources and tells an interesting story along the way.
Comments closedPat Wright asks the community about community:
Listed below is a summary of each person that took part and some of my comments related to the blog post. It was wonderful reading through the blog posts and getting different perspectives from others.
Click through for several posts on the topic.
Comments closedAndreas Scherbaum gets answers:
Last week for “PGSQL Phriday” I posted the following task:
Describe how you do backups for your PostgreSQL databases.
And I added a bonus question: Is pg_dump a backup tool?
Click through to see what people came up with.
Comments closedPat Wright explains why pg_dump isn’t the best solution for backup and restore:
I’m still fairly new to Postgres having only started about 5 years ago. I started with Pg9.6 and we quickly moved that environment to pg10. When I arrived at this company, pg_dump was the only backup we were using. The DB at that time was still around 50GB, it was reasonable to do the backups in a timeframe that worked for us. A dump was done every night and stored off to another server. After some time we started to test Pg_basebackup. This allowed us to full server backup each night. It was a huge improvement as far as speed and ability to handle much larger data sizes.
Read on for the tradeoffs around tools and various thoughts from Pat.
Comments closedGrant Fritchey brings an important insight:
I’m very much just beginning my journey of learning PostgreSQL. I’ve been documenting that learning over here at Simple-Talk (more on the way there), including backups. For this post, I’m not going to tell you about my “experience” maintaining a PostgreSQL backup routine because, well, there isn’t any. Instead, I have something else to say about backups that I learned, the hard way I might add, while working in SQL Server, that is 100% applicable to PostgreSQL.
Click through for Grant’s thoughts. The “what” makes sense. The “how” is the important part.
Comments closedRyan Booz shares some thoughts on backups in Postgres:
To be honest, I feel pretty unqualified to talk much about backups in Postgres, partially because it’s been a couple of years since I’ve had to manage the uptime of an application. As PostgreSQL has grown in popularity and usage, there is a lot of effort being put into tools like pgBackrest, pgBarman, and some newer solutions like pgcopydb (ok, I realize this isn’t billed as a “backup” tool, but…).
What I can share are a couple of things I’ve learned about restoring clusters and databases, particularly given the extensible nature of Postgres and the variety of tooling.
Read on for thoughts on a variety of topics.
Comments closed