Most are novices that have no idea how far the rabbit hole goes. I’ve been using postgres for about 25 years and every time I go to implement something with it I learn something new. I’m intermediate at best, and I’ve done things like rewrite the postgres wire protocols from scratch for internal use cases. This is especially true when I lean on the DB to take on new interesting roles (e.g. adding new operators for custom indexing of custom types, extending existing types in novel ways, adding new access methods, fun with foreign data wrappers, complex PITR and logical replication strats).
I'm a software engineer primarily. Postgres is another tool I like to use to solve data problems. I've used it as the backbone of applications in production at terabyte scale. I've architected and been responsible for the deployment of it, both on-prem and in "the cloud" (including the operations of PITR and replicated failover). I've written extensions for it, and hacked on the codebase for internal use.
The way I became a local Postgres expert - I skimmed through every chapter of the postgres manual, and read in great detail a great chunk of it.
I am responding to you because I learned to ask the right questions and how to communicate effectively.
Now, I may or may not have more experience than you - but if I can speak longer, without flinching, and answer you - correctly or with successful deflection - I am confident you will believe I am the expert.
I chose Postgres for my last production application because I did not know it. I knew mysql and sqlite and if I recall it was the only thing offered by whatever PaaS I was using.
A file is a file. A database is a database. A punch is a punch.
Grab three Postgres books. Read one of them cover to cover. Start the second. Skip everything you know from the first book. Start the third book. Double study everything that is contradicted between the three books.
Congratulations. You will be an expert according to those three authors.
Maybe most. But as someone supporting a company that has few TBs of data for SQL Server database to run Dynamics AX - they really appreciate when DBA makes their business run smoothly and get reports or calculate orders on time.
And I encounter multiple companies where they should need a touch of a DBA - weird database design that bites the business side of things.
Agreed, I've seen several examples of this.
Wow, did you also study time travel? /s
(Sorry I couldn’t help myself)