upvote
I think it would be helpful if some of these posts included scale. There are almost always two groups talking past each other

  - I run my B2B application, Postgres only, and it is perfect for my 50k MAU. No complaints, sleeping soundly with the low complexity and a two man team. 
  - I work at FAANG, where we have 1 billion DAU, and this is a joke. Would fall over immediately. The dedicated ops teams for Kubernetes, Elastic, and Redis have never complained about scaling issues.
reply
I broadly agree, but would tweak those numbers a little for small B2B apps: I ran a small B2B application on a cheap VPS using PostgreSQL as a primitive messaging interface, and even on a small VPS 50k DAU won't even cause the machine to break a sweat.
reply
i think 1 billion DAU is the exception here, so I would not expect everyone to constantly caveat personally.
reply
Agreed, but many of the criticisms I am reading here are assuming high scaling requirements and invalidating the approach entirely. When there are many business domains that will comfortably fit within a modestly specced database instance.
reply
Even just B2B vs B2C is a huge split. Plenty of specialized ERPs in the world that have relatively few "butts in seats" users but have a lot of data to work through.

Size of the data, read/write ratio, number of "requests"... lots of axes that change how much pain or not you're in by just pointing to pg

reply
deleted
reply
> Postgres does not even come close to a full replacement for Elastic

Size matters!

For most of the application out there elastic (or kafka or any other specialized tool) is just too much(and too costly). They can do fine with postgres or mysql. Actually, I'd argue that in a lot of cases even postgres is too much, probably sqlite is enough.

reply
The point is in general for people to just consider it, often people start out on their side projects or internal company projects and commission Elastic, Redis, Postgres, Kafka before even getting started. In reality they could fit it all into Postgres for a very long time.

Nobody is saying that a huge ecommerce store with complicated filtered search logic should throw away their Elasticsearch cluster and switch to Postgres.

reply
If you actually start looking into these things, you often start looking at custom pg extensions, which means you just made the decision to "simplify" your stack by maintaining your own postgres cluster with custom extensions. This is just papering over the fact that you're increasing the complexity and saying "well it's still just postgres!" as you do it.
reply
Installing & maintaining a Postgres extension is vastly, vastly simpler than running Elasticsearch and Kafka. Like, how could you even compare these things if you know what you are talking about?

Or maybe you are looking at it from "just swipe your credit card at AWS" perspective, in which case "just use Postgres" articles are for a different audience.

reply
Not really, most popular extensions are available on GCP/AWS (https://docs.cloud.google.com/sql/docs/postgres/extensions) out of the box and there's many things that you can easily run in Postgres without extensions (Queue, KV store).
reply
The power of the other tools mostly shines in large scales. For most applications, though, performance of postgres more than suffices.

I tried to use rabbitmq for a small app, installed it, configured it and then it didn't work. Spent a day jumping through hoops getting it right.

Dumped it and used postgres, in half an hour. Worked like a charm.

reply
Sure, best not to overcomplicate early if you don't need it.

PG is great and I work with it daily, but it's also not a problem to think about scale early and at least have a notional plan for what to and how to know when scale is becoming an issue in your system as you're designing it. Even PG is overkill and sqlite is more than enough for some of my projects.

There are a lot of specialized tools available, but you definitely don't need to put every one in your toolbox. Experience and observation help you make those edits -- and of course there's almost always room for improvement, but "good enough" definitely exists (until it doesn't anymore :D).

reply
This is the way. Notionally building a space/path to scale into architecture early, but delaying implementation of that scaling component until actually needed.

Then a system gets most of the benefits of not accidentally making it torturous to rearchitect for scale, without paying the headcount / complexity cost until it's needed.

reply
Would your app run equally well with sqlite?
reply
That's just it - most use-cases are pretty basic, and if you don’t know what you need then Postgres is probably a great place to start.

If you’re just starting out, keep things simple. Otherwise, you probably already know exactly why you need something more than Postgres.

reply
Postgres its all you need means to me(IMHO) postgres for all Olap (DB + message) , not all analytical databases.
reply
It can run analytics too, natively on some volumes of data, but also there are more specialized extensions.
reply
sorry all OLTP
reply
I'm partial to Typesense, especially for smaller data sets, since it runs primarily in memory, is easy to use and is hella fast. For bigger data sets, I hear good things about Meilisearch.
reply
You're right that vanilla Postgres doesn't come close to replacing Elastic. There are efforts to resolve this, though, like ParadeDB: https://github.com/paradedb/paradedb (disclaimer: I work for ParadeDB)
reply
I see Tantivy mentioned in your readme but AFAICT there is no PG-Tantivy sync. I also see "native vector support is coming to our search index soon". Could you clarify?

What do you suggest for a language like Malayalam which has no native support, preferably with low RAM requirements?

reply
"Disclaimer" means "don't take this seriously because I'm not an expert". You mean "disclosure".
reply
My English fails me again :'). Thank you for the correction!
reply
I have a lot of troubles with a small private instance of Rocket chat, all due to MongoDb stuff, versions, migrations and backups. I bet almost all private instances of Rocket chat would be perfectly served with Postgres.

Posts like this can be tiresome, yet the general consensus among developers seems to be "yeah, Postgre/SQLite is ok for 99% of the cases, but MY case is going to be in the 1%, because I am going to be the next Facebook".

reply
Fwiw, I, as someone who has worked on Postgres for a long time, also find it quite tiresome. Like there's plenty stuff I wouldn't use Postgres for, and I can probably get get more out of it than most.
reply
Exactly - these recommendations often come with no context or scale provisions.

Yes Postgres can work in the small for a lot of things, it can even work at surprising scale if you use it according to its strengths.

But if you use it for things it doesn't shine at, at inappropropriate scale - you'll almost certainly run into issues. And resolving those can often be a bigger challenge than choosing a more suitable solution in the first place. But often I think younger/less experienced engineers just have to burn themselves, thus why this never seems to die.

reply
if you need elastic youre doing something wrong
reply
Or something big. Which is often not wrong.
reply
deleted
reply