/Database

Database Design For Google Calendar: A Tutorial

- Alexey Makhotkin tl;dr: “In this database design tutorial I’m going to show how to design the database tables for a real-world project of substantial complexity. We’ll design a clone of Google Calendar. We will model as much as possible of the functionality that is directly related to the calendar.”

featured in #519

Common DB Schema Change Mistakes

- Nikolay Samokhvalov tl;dr: Nikolay covers 18 mistakes, categorized into three big categories of DB schema migration mistakes: "(1) Concurrency-related mistakes. (2) Mistakes related to the correctness of steps. (3) Miscellaneous – mistakes related to the implementation of some specific database feature or the configuration of a particular database."

featured in #511

Database Fundamentals

- Tony Solomonik tl;dr: "I tried thinking which database I should choose for my next project, and came to the realization that I don't really know the differences of databases enough. I went to different database websites and saw mostly marketing and words I don't understand. This is when I decided to read the excellent books Database Internals by Alex Petrov and Designing Data-Intensive Applications by Martin Kleppmann. The books piqued my curiosity enough to write my own little database I called dbeel. This post is basically a short summary of these books, with a focus on the fundamental problems a database engineer thinks about in the shower."

featured in #508

Database Fundamentals

- Tony Solomonik tl;dr: "I tried thinking which database I should choose for my next project, and came to the realization that I don't really know the differences of databases enough. I went to different database websites and saw mostly marketing and words I don't understand. This is when I decided to read the excellent books Database Internals by Alex Petrov and Designing Data-Intensive Applications by Martin Kleppmann. The books piqued my curiosity enough to write my own little database I called dbeel. This post is basically a short summary of these books, with a focus on the fundamental problems a database engineer thinks about in the shower."

featured in #507

Understanding DynamoDB Secondary Indexes

- Alex DeBrie tl;dr: Indexes are a crucial part of proper data modeling for all databases, and DynamoDB is no exception. Alex DeBrie, author of The DynamoDB Book, explains the problems secondary indexes solve, how to use them effectively, and how to choose between secondary indexes and alternatives like Rockset.

featured in #503

How LedgerStore Supports Trillions Of Indexes At Uber

- Kaushik Devarajaiah tl;dr: “LedgerStore is an immutable storage solution at Uber that provides verifiable data completeness and correctness guarantees to ensure data integrity for these transactions... This blog covers the significance of LedgerStore indexing and its architecture, which powers trillions of indexes, with a petabyte-scale index storage footprint.”

featured in #503

The Problem With Using a UUID Primary Key In MySQL

- Brian Morrison tl;dr: “UUIDs especially useful in a distributed architecture, where you have a number of systems and databases responsible for creating records. You might think that using UUIDs as a primary key in a database is a great idea, but when used incorrectly, they can drastically hurt database performance. In this article, you'll learn about the downsides of using UUIDs as a primary key in your MySQL database.”

featured in #502

DuckDB As The New Jq

- Paul Gross tl;dr: “Recently, I’ve been interested in the DuckDB project. And one of the amazing features is that it has many data importers included without requiring extra dependencies. This means it can natively read and parse JSON as a database table, among many other formats.” Paul discusses how this has impacted his work. 

featured in #499

How Figma’s Databases Team Lived To Tell The Scale

- Sammy Steele tl;dr: “The data revealed that some of our tables, containing several terabytes and billions of rows, were becoming too large for a single database. At this size, we began to see reliability impact during Postgres vacuums, which are essential background operations that keep Postgres from running out of transaction IDs and breaking down. Our highest write tables were growing so quickly that we would soon exceed the maximum IO operations per second supported by Amazon’s Relational Database Service. Vertical partitioning couldn’t save us here because the smallest unit of partitioning is a single table. To keep our databases from toppling, we needed a bigger lever.”

featured in #498

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