I like Postgres. It is a good general purpose database. I like other databases too. Other databases can do some things that Postgres can't do as well.
PostgreSQL for Everything
51–60 of 286 posts
Re: PostgreSQL for Everything
#52This kind of post (Postgres! It's all you need!) is getting pretty tiresome. Postgres does not even come close to a full replacement for Elastic, and that's just the first bullet. Looking down the list it is pretty easy to go: Yes, postgres can be used instead of that for extremely basic use cases, but it all goes out the window you actually need any of the power of these other tools.
Postgres its all you need means to me(IMHO) postgres for all Olap (DB + message) , not all analytical databases.
Re: PostgreSQL for Everything
#53As usual, it depends on the scale, but it's a sane default for 99% of use cases.
Different use cases have different scalability limits in PG, when you get to them you need to deal with them.
It would be perfect if it had somewhat transparent sharding, I mean a way to add another instance and distribute load without having to stop everything.
There are solutions, but they tend to be involved and when you get to that point in many cases it makes sense to just move that workload to something else that scales better.
Re: PostgreSQL for Everything
#54This kind of post (Postgres! It's all you need!) is getting pretty tiresome. Postgres does not even come close to a full replacement for Elastic, and that's just the first bullet. Looking down the list it is pretty easy to go: Yes, postgres can be used instead of that for extremely basic use cases, but it all goes out the window you actually need any of the power of these other tools.
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.
Re: PostgreSQL for Everything
#55[dead]
Re: PostgreSQL for Everything
#56"MySQL was also potentially faster as it did not implement all features of the SQL standard. " This is a not great start. I assume it refers to MyISAM which has not been relevant for over a decade at this point. InnoDB made different design than PG decisions and was (and perhaps still is) faster at point lookups.
Well, the poster explicitly talks about 2003 here: „ In 2003, MySQL was much more widely used than PostgreSQL. MySQL was also potentially faster as it did not implement all features of the SQL standard“
Didn't very early mysql play fast and loose with the concept of actually syncing to disk? That was also fast. Web scale fast. :)
Re: PostgreSQL for Everything
#57Postgres is great, but I certainly don't think it's great for everything. For instance, while you can in theory implement OLAP aggregation you're going to be hand-rolling a bunch of stuff that something like Clickhouse gives you for free declaratively.
I don't think the point is that PostgreSQL is great for everything. But you may get by with a single piece of infrastructure instead of 7. In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we o…
The article says verbatim “PostgreSQL Replaces Clickhouse”.
Coming from storing billions of rows in Clickhouse and performing dozens of materialized operations I shudder to think about what that would look like in a DB that doesn’t even support declarative IVM.
Re: PostgreSQL for Everything
#58Honorable mention - https://postgrest.org/
Re: PostgreSQL for Everything
#59true to that - currently using psql (in a single monolithic codebase) as: sql db, json db, vector store, logs store, full-text search, queue, message bus. multiple processes connected to it.
[dead]
Re: PostgreSQL for Everything
#60Hardware is so far nowadays to make people with little systems knowledge confident to make such claims at least from their use cases. However it is neither generally reasonable nor efficient.