I’d be careful of anyone who says they’re a “postgres expert”; I respond the way I respond to self-proclaimed C++ experts: “oh yeah? tell me more”
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.
I've read a bunch of the official documentation, and then read a lot of the source code to Postgres itself. I'd say source is the #1 place I go if I have questions that are specific, and then if I want philosophy I look for previous presentations by the Postgres team, or from the hackers mailing list.
Yah, I have had many projects where I could have used something else, but Postgres ended up being the perfect bag of tools to do what I needed. I've been very happy with it.
I can understand. I started to grasp the full potential of Postgres (but probably I'm still missing a lot) when I decided to use it for time series with the Timescale extension.
I was considered for a long time a "local" Postgres expert (as in, the person that knew the most about Postgres at my employer). That's not the same as an industry-level Postgres expert.
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.
Background: I have been paid for IT work for 20+ years - mostly as a Consultant or SME (subject matter expert).
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.
FWIW, I have billed myself as a PostgreSQL expert and did general technology consulting for a long while; I started using PostgreSQL back like... 25 years ago? I also was using SQL Server and like DBase or FoxPro something back around then (while consulting with a friend--while we were in high school--for some local companies that were excited about the idea of this newfangled Internet thing they were hearing about).
I'm not a postgres expert but I wouldn't be surprised if the people selling themselves as such were previously sql server or oracle experts. I've done both over the last 25 years and followed their certification path, but I'm not sure this particular expertise is a marketable these days, for many companies dbs are a commodity. I've moved more into cloud solution architecture now.
Yeah I guess these days it's easier to setup a DB if you have a cloud env. Also most companies don't need (or want) their DB optimized by an expert. Why did you move to cloud architecture?
> Also most companies don't need (or want) their DB optimized by an expert.
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.
Studied database theory at uni (20002-2004) -> a few years of work with Ora and MS -> startup, attempt to use MySQL (in 2005), cannot use it after all those others -> switched to Postgres, rewriting all the code code in a few days -> happy Postgres user since then, no regrets (though, I can name a lot of issues with Postgres, it's still the best)
I hired a guy years ago for a project who was an "Oracle expert." I would have put that guy on any project involving databases as while he clearly knew Oracle inside and out, I have no doubt his knowledge would have transferred in some form to other platforms. Can you make a living being a "Postgres expert"? That's hard to say. Anymore if I were hiring someone I might want them to have more know-how that just the guts of a database, IE: I'd want them to know something about the systems on top of the database so that they can make stronger recommendations.
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).