/PostgreSQL

Implementing Stripe-like Idempotency Keys In Postgres

- Brandur Leach tl;dr: “In APIs idempotency is a powerful concept. An idempotent endpoint is one that can be called any number of times while guaranteeing that the side effects will occur only once. In a messy world where clients and servers that may occasionally crash or have their connections drop partway through a request, it’s a huge help in making systems more robust to failure. Clients that are uncertain whether a request succeeded or failed can simply keep retrying it until they get a definitive response.”

featured in #535


Postgres Is All You Need, Even For Vectors

- Eric Zakariasson tl;dr: “When working with LLMs, you usually want to store embeddings, a vector space representation of some text value. During the last few years, we’ve seen a lot of new databases pop up, making it easier to generate, store, and query embeddings: Pinecone, Weaviate, Chroma, Qdrant. The list goes on. But having a separate database where I store a different type of data has always seemed off to me. Do I really need it?”

featured in #524


Taking Random Samples From Big Tables

- Eric Fritz tl;dr: “You’ll learn how to randomly sample large datasets in PostgreSQL while keeping your queries performant. Instead of telling you “the answer,” we’ll walk through possible solutions and their tradeoffs, and help you build a deeper understanding of databases.”

featured in #524


Making A Postgres Query 1,000 Times Faster

- Alejandro García Montoro tl;dr: Alejandro describes optimizing a Postgres query that powers Elasticsearch indexing. The original query took over 24 seconds due to processing the entire posts table. By using row comparisons instead of separate conditions, the optimized query runs in 34ms - a 1000x speedup. However, the same optimization makes the MySQL version 50x slower.

featured in #516


The Notifier Pattern For Applications That Use Postgres

tl;dr: “Listen / notify in Postgres is an incredible feature that makes itself useful in all kinds of situations. I’ve been using it a long time, started taking it for granted long ago, and was somewhat shocked recently looking into MySQL and SQLite to learn that even in 2024, no equivalent exists.”

featured in #512


How Levels.fyi Built Scalable Search With PostgreSQL

- Tanishq Singh tl;dr: The post outlines how Levels.fyi built a scalable fuzzy search solution using PostgreSQL that handles over 10 million search queries per month with p99 query performance under 20ms, outlining the key steps. 

featured in #504


Postgres Is Eating The Database World

- Ruohang Feng tl;dr: “PostgreSQL isn’t just a simple relational database; it’s a data management framework with the potential to engulf the entire database realm. The trend of “Using Postgres for Everything” is no longer limited to a few elite teams but is becoming a mainstream best practice.”

featured in #498


Looking Back At Postgres

- Murat Demirbas tl;dr: The Postgres origin story: “Riding on the success of Ingres project at Berkeley, Stonebraker began working on database support for data types beyond the traditional rows and columns in the early 1980s. A motivating example was to provide database support for CAD tools for the microelectronics industry, including "new data types such as polygons, rectangles, text strings, etc...

featured in #483


How We Migrated Our PostgreSQL Database With 11 Seconds Downtime

- David McDonald tl;dr: “Our source database is about 400GB in size. It has about 1.3 billion rows, 85 tables, 185 indexes and 120 foreign keys. It is PostgreSQL version 11. On a usual weekday, we do somewhere in the region of 1,000 inserts or updates per second, plus a similar number of reads.” The DB is relied upon to send millions of important and timely notifications each day, from flood alerts to updating users about their passport applications . 

featured in #482


An Overview Of Distributed PostgreSQL Architectures

- Marco Slot tl;dr: “What many users notice within the first few minutes of using a distributed database is how unexpectedly slow they can be, because you quickly start hitting performance trade-offs. There are many types of distributed PostgreSQL architectures, and they each make a different set of trade-offs. Let’s go over some of these architectures."

featured in #479