- 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
PostgreSQL for Everything
81–90 of 286 posts
Re: PostgreSQL for Everything
#82Honorable mention - https://postgrest.org/
I find it odd that this isn't mentioned anywhere in an article about using postgres for everything.
Re: PostgreSQL for Everything
#83Earlier quoted context omitted.
MySQL was always behind in terms of features. In early 2000s it had very limited constraints. Most people were running in ISAM backend and did not even have transaction support. It was being used by people who did not understand how advanced relational DBs were being used. What changed is Postgres overtook its actual competition, which were Oracle, SQL Server and Sybase. MySQL caught up as well as far as I know, but…
In the early days, PostgreSQL was so much more awkward to deal with. Crash-prone at first, and then there was the whole business around having to drop the db during upgrades. It didn't really match MySQL operationally until around 2002. During the dot com era it was common to develop and launch on MySQL with the intention of migrating to something else if they became successful (though your typical LAMP stack develop…
I would agree with that, although I personally found it preferable in 2001-2002, since it matched the feature set of SQL Server in all the important ways that MySQL didn't. I think it may have been late 2000s before it was clearly preferred for new projects and even later before it was the thing you had to explain why you weren't using it.
edit to add: MySQL did have operational advantages even later than mid 2000s since it had master/master replication from very early (I don't know how sound it was, I doubt it was perfect). That was a real reason to choose it. We still don't have it in Postgres without extensions and even there citus is not really the same.
Re: PostgreSQL for Everything
#84> PostgreSQL Replacing Your Microservice
I've done that before and the code was a mess. It works at the beginning but APIs do much more than piping data from the database. When you start dealing with ACL, external calls, code reuse, etc. It's just nice to have all the tools available to you from something like Python or Go.
Re: PostgreSQL for Everything
#85Surprised it doesn't mention LISTEN / NOTIFY.
Re: PostgreSQL for Everything
#86One addition: Postgres for all your GPU-based machine learning training and inference needs: https://github.com/postgresml/postgresml
Re: PostgreSQL for Everything
#87I 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.
The main issue with SQLite is the very poor type system, after testing it for an app I was shocked.
Are you saying that STRICT was insufficient for you? What more did you want beyond one of: INT, INTEGER, REAL, TEXT, BLOB, ANY?
Re: PostgreSQL for Everything
#88Postgres 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.
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.
Re: PostgreSQL for Everything
#89How do you implement HA in postgres, i found MySQL HA stack pretty straight forward with Innodb cluster, MySQL router and Shell.
https://patroni.readthedocs.io/
But I sure wish it was 'core' and we didn't have to worry about it potentially going away, becoming de-supported..
Re: PostgreSQL for Everything
#90It'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 den…
I think you’re responding to the general idea of a relational database, not Postgres, and definitely not what’s in the article (DR;CA).
Postgres has built in data types and functions that allows it to work with unstructured json documents, like you would use in MongoDB.