PostgreSQL

27 January 2026 19:01

There are plenty of times where a composite primary key makes the most sense. I would say if you've got more than two columns in the PK, to maybe think it through some more.

I also in general try to use natural keys where they exist, rather than surrogate keys for the sake of surrogate keys.

In the case of many to many link tables, I often find they get used way more than they should, and often highlight a missing entity between the two.

PostgreSQL

27 January 2026 11:03

But you lose the simplicity in the junction table, of.

ID, user_ID, submission_ID, ...

You made it harder, IMO.

Just drag the 2 columns with you, everywhere...

PostgreSQL

27 January 2026 09:30

...yes? Which means you need to load the source table for further data, of course, or at least its own indexes.

PostgreSQL

27 January 2026 09:09

Well, ofc you can. In fact, don't you have to?

But in almost 30 years of DB work. I've learned SO MANY lessons.
1) Avoid composite PKs
2) Prefer Sequence/GUID (artificial) PKs
3) Prefer all such PKs have the same name in all tables (id), and as fks, they are source_table_id

Honestly, we are currently in the middle of a 1+yr project to remove these "Composite Keys" from a project.
Everyone regrets that the old DBA did this. (Admittedly, he used an UGLY approach).

But life is SO MUCH easier if you use artificial FKs. And they are all the same everywhere.
We use BIGINT. And it allowed us to validate every FK was properly a BIGINT as well.
From the system we can from (Oracle)< we had some PKs that were HUGE, medium, small sized.
And the FKs were stored in randomly sized numeric fields.

One size (BIGINT) for all. Yes, even for tables that will never have more than 2,000 items or 100 items.
Sorry, with ~ 1,000 tables. You get sick and tired of fixing query or ::TYPE type forcing things.

YMMV.

but I can't tell you how easy it is to add: ORDER BY id DESC; to a query to see the most recent data.
regardless of the table. You just get spoiled by it.

And the JOIN other ON other.car_ID = car.ID

almost writes itself...

PostgreSQL

27 January 2026 08:12

Sure, Hans-Jürgen's (in)famous talk.
It's quite hard to find tbth:
https://www.cybertec-postgresql.com/en/next-stop-joining-1-million-tables/

PostgreSQL

27 January 2026 01:03

I have this memory of a talk in the last few years about a billion-table PostgreSQL instance. Does that ring any bells?

PostgreSQL

26 January 2026 22:23

I need that for cascading purpose.

I have foo, bar and baz main tables. There is juncture table between foo and bar, there is also juncture table between bar and baz, and whenever juncture between bar and baz is created I want to automatically create a juncture row between baz and foo. And whenever the link between foo and bar or bar and baz is broken I need to automatically delete the link between baz and foo.

PostgreSQL

26 January 2026 21:12

Team any one has postgre tutorial material

PostgreSQL

25 January 2026 22:59

Hey all,

Data Bene is looking for a number of positions to be filled. They're open to contract work, and are headquartered in France but are hiring globally. https://www.data-bene.io/en/jobs/

In particular, they're looking for anyone who would love to do R&D with open-source technologies. Experience with C is great. They're specifically looking for PostgreSQL support engineers, consultants, & technical leads.

PostgreSQL

23 January 2026 23:00

Hello friends, I have a question, I installed PostgreSQL V17 with postgis 3.8 and I run it from Both QGIS and myadmin, the problem is that when I try to add table in QGIS, it gave me an error, and when I log to myadmin, I find that no table was added. How can I fix that and how to synchronize between QGIS and myadmin

PostgreSQL

23 January 2026 10:14

Well, let's hope nobody accidentally closes that window!
I'll see myself out...

PostgreSQL

23 January 2026 10:07

Scaling PostgreSQL to power 800 million ChatGPT users | OpenAI
https://openai.com/index/scaling-postgresql/

PostgreSQL

20 January 2026 10:18

New supabase yes or no

PostgreSQL

20 January 2026 06:37

Maybe postgres services are for low skill teams

PostgreSQL

20 January 2026 06:34

Or just buy service that closes gap between low and ultra high load

PostgreSQL

27 January 2026 13:00

+1 and always start with - ( minus signed ) for long lasting pkey sequence.

bigint covering 2^64 unique number. from -2 ^ 63 to 2 ^ 63. its huge.

PostgreSQL

27 January 2026 09:34

But I would argue that this is one case where it may make more sense to use a composite primary key. For example I have a submission_favourites table, a many to many junction of users and (art) submissions. That table actually had its own artificial primary key provided by the original DBA but I removed it because the composite key was sufficient (and actually the same size as the artificial primary key would have had to be, considering there could be billions of +favs).

PostgreSQL

27 January 2026 09:12

Yeah, I agree with this, but how do you do junction tables at many to many relationship? Its id as primary key + ids it is joining as a unique value?

PostgreSQL

27 January 2026 08:13

(it *should* be referenced in that talk)

PostgreSQL

27 January 2026 06:25

Any one having postgresql material pls

PostgreSQL

26 January 2026 22:27

As long as the fields o the referenced table are covered by a unique index yes, and you create a fkey ON DELETE CASCADE

PostgreSQL

26 January 2026 22:21

Can I use composite primary key as a foreign key?

PostgreSQL

26 January 2026 20:43

Can I get postgresql dba tutorial material pls

PostgreSQL

25 January 2026 22:53

Did you *read* the error message? Probably a permission problem.

PostgreSQL

23 January 2026 19:38

Well, it is Azure... windows are their thing.

PostgreSQL

23 January 2026 10:07

"The system (initially created by a team of scientists at University of California, Berkeley) has enabled us to support massive global traffic with a single primary Azure PostgreSQL flexible server instance⁠(opens in a new window)"

PostgreSQL

20 January 2026 10:21

Should they at least add two daughter projects: Supabase-✅👍! and Supabase-№ ..?

PostgreSQL

20 January 2026 07:20

skill = money, and no most of mid tire services are significantly cheaper than DBA that will not lose your data (or leak it)

PostgreSQL

20 January 2026 06:35

But it's more expensive than your own servers?

PostgreSQL

20 January 2026 06:34

Scales better - costs significantly more