PostgreSQL

31 January 2026 17:56

btw, since the topic of dba jobs came up...
what are some roles that focus mostly on the database?
what I see is either teams looking for backend developers who do database stuff (mostly via ORMs) or enterprises looking for experienced DBAs (and oracle is a common thing)

is there anything in between?

PostgreSQL

31 January 2026 17:48

For example u can setup DBMS in 1 click. Also u can just delete the docker container and setup DBMS again in 1 click. Also u can setup another DBMS instance in 1 click (for unsafe tests for example)

PostgreSQL

31 January 2026 17:41

And MySQL makes seniors angry

PostgreSQL

31 January 2026 17:36

Jokes aside, what caused the most pain? I know some features like filetables are not supported, but "regular" things work fine 🤔

PostgreSQL

31 January 2026 04:27

buying sql server license is my biggest regret in my life.
i feel very stupid.

PostgreSQL

30 January 2026 18:43

I am looking for a change in job.

PostgreSQL

30 January 2026 07:21

What type of resume you want

PostgreSQL

28 January 2026 03:41

we can use .env for our anon key and project url to save the keys import from that

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

31 January 2026 17:50

yeah, docker is definitely one of the best things ever made... but working with the OS directly isn't something "outdated". One should choose the best method that works for them

PostgreSQL

31 January 2026 17:44

They provide docker image of SQL server. Does someone install DBMS on host os in 21th century? Did u try docker?

PostgreSQL

31 January 2026 17:38

Ms sql? It is cool DBMS for big serious production because there are a lot of stable cool serious instruments

PostgreSQL

31 January 2026 04:32

Trying SQL Server on Linux was my second regret.

PostgreSQL

30 January 2026 21:29

First suggestion: get rid of the "sql means SQL Server" mindset.
Second: SQL will be around for a long time. But people will not be willing to pay tons of money for it. Which essentialy means they will end up using PostgreSQL...
Third: yeah, acquiring PostgreSQL knowledge will benefit you

PostgreSQL

30 January 2026 18:43

I am an sql dba with 6+ years of experience. Does learning postgresql dba will give more weight to my resume.? Or any other suggestions..?

PostgreSQL

29 January 2026 17:13

Anyone send me sample resume for postgressql dba

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