201–210 of 286 posts
My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres." Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.
Earlier quoted context omitted.
With Lakebase Postgres you can do this very easily: https://docs.databricks.com/aws/en/oltp/projects/quickstart-... It is already a quite smooth experience, but there is work to make it even easier than that. I work on Lakebase, opinions my own.
As a big fan of Postgres, Databricks and Lakebase: Lakebase is not Postgres, and this is just CDC.
Earlier quoted context omitted.
If you start here, with the "Postgres will take you wherever you need to go" meme, without thinking extremely deeply about your schema and how you expect to evolve it in the future, you can easily paint yourself into a very difficult and expensive corner. It's easy to use Postgres poorly in ways that result in painful centralized bottlenecks. (Obviously this is largely true for anything , but I think that in 2026, wh…
A counter anecdata. We transitioned from a postgres job queue to Rabbit. We had never ending problems after that, many of them were misunderstandings, some where just wrong-fit. We migrated because we had some time on our hands and thought we would alleviate some high pressure jobs. Not only did it not solve the problem, but having written all the code that decides when to pull the next message and what to do with it…
This isn't just theory either, for example: Revolut is a bank that does all its event persistence and streaming on top of postgres. No traditional message queues/brokers in their stack. https://medium.com/revolut/recording-more-events-but-where-w...
If you start here, with the "Postgres will take you wherever you need to go" meme, without thinking extremely deeply about your schema and how you expect to evolve it in the future, you can easily paint yourself into a very difficult and expensive corner. It's easy to use Postgres poorly in ways that result in painful centralized bottlenecks. (Obviously this is largely true for anything , but I think that in 2026, wh…
My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres." Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.
The issue with this general rule of thumb is that we can swap Postgres for many others, including non-relational, and it works.
use what you're familiar with, until it stops working. then use something else. postgres just goes a lot further than a lot of other tools before you get to the "use something else" phase. and postgres is the database a lot of people are familiar with.
I wanted to see how far I could push that toolset. It worked surprisingly well. Django's capabilities meant such things as multi-user login pages, access controls and remote monitoring were very easy.
Anyway databases nowadays are a commodity. A sticky commodity but nonetheless they are replaceable; increasingly so in the age of AI where data migrations are easier than ever.
Earlier quoted context omitted.
If you start here, with the "Postgres will take you wherever you need to go" meme, without thinking extremely deeply about your schema and how you expect to evolve it in the future, you can easily paint yourself into a very difficult and expensive corner. It's easy to use Postgres poorly in ways that result in painful centralized bottlenecks. (Obviously this is largely true for anything , but I think that in 2026, wh…
It’s also entirely possible that nothing you do in the eventual history of your company hits a scale where this matters.
While the GP may have been referencing the former, embracing "PostgreSQL for Everything" often prohibits the latter.