The integer used by the Django data model is an Int, but the database used BigInt. The discrepancy occured for the row IDs greater than the maximum value of the int.

Specifically, several tables—including this one—were specified as using an int for their primary key in Django, but used bigint in the real database.

Storing the raw blobs data has one advantage: no data is lost and they can be refined by need.

IDE references can be thrown into postgres in order to retrieve them.

Handling chinese characters in a JSONB column and a dictionnary.

or (of course) temperature changes

An implementation for UUIDv7 was committed to Postgres earlier this month. These have all the benefits of a v4 (random) UUID, but are generated with a more deterministic order using the current time, and perform considerably better on inserts using ordered structures like B-trees.

A list of things to avoid

A nice piece of technology that is developed here

Visualizing and understanding PostgreSQL EXPLAIN plans made easy.

Not sure why this is, but I’m guessing it’s got something to do with working with a schema. It exercises the same sort of brain muscles1 as designing data structures or architecting an application.

Full of advices on these misused and abuses

the goal for rainfrog is to provide a lightweight, terminal-based alternative to pgadmin/dbeaver.

That's very interesting

This is why databases accessed over a socket instead of being an embedded library are actually a great abstraction, not necessarily a technical one, but an organizational abstraction! During development it can be a simple container running on your developers machines, while in production it can be anything from a container running on the same server as your application, or a distributed cluster accessed through the network.