- mind coming and enligtening about PostgreSQL and XML?

- https://www.reddit.com/r/PostgreSQL/comments/1vbo5j8/raw_xml...

- your post did not have a single word on XML hence my comment

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...

> Timescale lately released the pgvector extension, that turns your PostgreSQL into a vector database.

I don't think this is accurate and smells like an LLM hallucination to me.

From the Timescale/Tiger Data _pgvectorscale_ project's README:

> pgvectorscale builds on pgvector with higher performance embedding search and cost-efficient storage for AI applications.

I think this is where the confusion originates.

As an aside, I've used Timescale/Tiger Data products and was very happy with them and their support. Their team was very engaged and responsive to all of our questions. They also fixed a pretty gnarly indexing bug I uncovered in pgvectorscale in an impressively short amount of time.

I use SQLite for everything, and I'm perfectly happy with it. I'm aware of the concurrent writer issues, but at my scale it doesn't even matter.

This 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.

Ive built data warehouses and job queues on postgres. The DW got replaced with bigquery when we started doing more tracking. We still run postgres as an app-facing cache of the aggregated data from bigquery though.

The job queue runs on the cache db, scheduling jobs to move data from bigquery into postgres. It’s pretty neat.

Now we’ve run into near-real-time requirements so clickhouse is getting thrown into the mix.

It’s pretty funny the lengths we go to to implement user facing analytics that’s basically just “you are visitor number X” from 1995.

Nice one re: flatbuffers in `blob` column. Have been working with flatbuffers a lot and that's a neat idea in general.

Not 100% sure about using PG for file system at scale however. I'd love to hear more on the challenges (vacuum, toast, anything else?)

PostGIS is also another very useful addition for storing, indexing, and querying geospatial data.

http://www.postgis.net

No mention of https://postgis.net/ - shameful

if you are searching for something similar but with more meat: https://ebellani.github.io/blog/2026/all-you-need-is-postgre...

It's more "what one tool can do everything", not that its ideal. Like why people use Microsoft Teams even though its terrible.

The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them.

Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a denormalized mess and everything is hacked around it.

Instead of modeling things in the proper way, most of the world's data is modeled in a way so that we don't have join explosions in sql queries because they look scary. Data pipelines become these scary batch transformations where data is dumped somewhere else without anyway to trace back where it came from.

I encounter so many end-user applications and systems where you wonder: "why couldn't they allow a list of items here instead of a single box" or "why can't this reference this other thing".

sqlite for everything

NVMe drives + Litestream + object storage(S3/R2..). sqlite simplifies things for the entire long tail of apps/services that aren't the Ubers and AirBNBs of the world.

As 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.

How do you implement HA in postgres, i found MySQL HA stack pretty straight forward with Innodb cluster, MySQL router and Shell.

How many production system has serious queues using PostgreSQL?

SQLite has so many advantages over PostgreSQL.

No deamon. Single file per DB. Less configuration overhead.

I tend to agree with quite a few points in the article, but some topics warrant some careful scrutiny.

* As a message queue: Only if your required features are very basic, like if you need cluster communication and run your own coordination protocol on top.

* High Volume Time Series: TimeScale works, but composes badly with other workloads on the same DB server ( from an operational perspective at scale )

* Vector Database: The same issues as with TimeScale.. PgVector for example lives in its own seperate "world" and the query planner sees it as a very opaque thing. Forget about adding vector storage to an existing high volume db, that must server other complex queries.. PGVector will either trash your caches, or take over your cpu so that workloads that used to work fine stall. This is IMO not a pgvector problem itself ( Kudos to those guys ) but rather that postgresql extension apis are not very good at exposing custom costs and tradeoffs to the system as a whole.

* Raw Data: Works for small files... why anyone would want to store large amounts of data in it would be a mystery, where it shines is accessing LOTS of small files where internal caching etc help a lot compared to raw filesystem access ( also a bit dependent on the filesystem and its tuning though )

* Microservice: If your service is ONLY exposing json data from some database model, then it should not exist at all IMO. Create a view and be done with it.

Postgres 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 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.

I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it.

MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues.

That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned.

yes. my people.

https://github.com/seanwevans/pg_gpt2

https://github.com/seanwevans/pg_shell

https://github.com/seanwevans/pg_os

Can Partitioning be used to move data to S3 Storage, for long term archiving?

Why write a fanboy text with unfair comparisons that hide the Postgres limitations?

For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.

* No need for a connection pool, while many use cases with Postgres require PgBouncer and Co.

* Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations.

* No need to VACUUM, which can be a hard problem (it was, the last time I used Postgres).

For full text search, I once worked on a project that considered several alternatives for this, including Postgres. Manticore Search was finally chosen because it was more performant, with better search results.

The older I get the more I agree with this

Honorable mention - https://postgrest.org/

true 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.

isn't the process per connection restriction pretty heavyweight though?

there is also https://postgresforeverything.com/

Hardware 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.

the more ive coded the more this is true

For the graph database idea in Postgres, PG 19 has native support for property graphs [0]. You can set up your tables and their relationships as nodes/edges, then query against them using Cypher-esque [1] syntax.

0: https://www.postgresql.org/docs/19/ddl-property-graphs.html

1: https://www.postgresql.org/docs/19/queries-graph.html

"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.