Software Engineer, Author, Consultant
This past week I had the privilege of presenting at and attending RailsConf 2022 Conference in Portland, OR. My presentation was titled Puny to Powerful PostgreSQL Rails Apps. This post will focus mainly on my presentation experience.
Recently I had the opportunity to travel to NYC to present at PGConf NYC 2021.
In the StaffEng book, there is a section called Work on What Matters.
Duplicate rows can happen when a database unique constraint is missing. Once found, finding and deleting duplicates in a fast way is necessary before the constraint can be added.
By using UNLOGGED tables, we can insert rows at a higher rate when compared with a logged table (the default). But there’s a trade-off.
Over time our indexes became bloated, meaning invisible rows were still present in the index. This is inefficient and can be addressed by rebuilding the index.
This tip is a recipe for how to recover from a Rails migration that failed to apply in production. This process could work for any SQL migration. The example below is for an index added to a table.
We operate a high scale API application that relies on a single primary PostgreSQL instance. We have scaled up the DB instance vertically, acquiring more CPU, Memory, and disk IO over time.
Indexes are data structures designed for fast retrieval. For databases with high row counts, Indexes that match queries well are critical to achieving good performance.
Authentication and authorization with JSON technologies can be a confusing mess of acronyms, so this post is an attempt to sort these out. This post including the title, is very similar to Red Thunder: JWTs? JWKs? ‘kid’s? ‘x5t’s? Oh my!....