PostGres is enough, but is it fast to code?
Digging into the examples, there’s two separate claims in which “PSQL is enough” according to today’s top post on HN.
PSQL can handle all your data
PSQL can handle all your data operations
A simple difference
The difference between data and operations can be explained with two examples:
example 1 I need to store customer records and have a message queue for incoming requestions. I could do it in psql for storage and redis for queuing, or just psql.
example 2 I need to store customer records and run a cron job on them daily. I could do it in psql for storage and use a system cron, or I could do cron within psql.
PSQL can handle all your data
The claim is you don’t need to use other dbs, you can do it all with psql.
This is awesome for a fast coder. You don’t need to use a different technology for things like nosql, graphql or message queuing. We can use one technology (that we know well) and one environment for all of our data. We can specialize in an all purpose tool that’s stable, well tested, well documented, well known, and chat gpt knows a lot about. We don’t have to worry about where the data is, it’s all in psql! We can view all of our data at once. We only need one toolchain, to learn one set of commands (ex: is it \d or show tables;). It’s just so much faster when all of your data lives in one technology.
PSQL can handle all your data operations
The claim is you don’t need to compose psql with other technologies for things like cron jobs and calling APIs. You can do it in psql itself.
This is mediocre for a fast coder. On the one hand, it means we don’t have to learn another technology stack or setup a new tech stack or any of the other benefits mentioned above. On the other hand, composing technologies is historically more powerful, robust, and faster than trying to do everything in one environment.