The fact that PostgreSQL is pigeon-holed as a "database" blinds folks to the fact that it is also a full-fledged integration environment. It's a place where you can bind together multiple kinds of data and multiple kinds of application.
* Use FDW connections to pull in data from all kinds of sources! Multiple databases, file formats, HTTP buckets, you name it!
* Custom behaviours in multiple languages! PL/Python, PL/Perl, PL/R!
* Read and write to web services! (PL/Python, pgsql-http)
* And now string together arbitrary containers! (pgpodman)
The way the extension system and the type system play together, it really is a very generic place to build weird integrated systems.
Essentially, this (as I understand it) is highlighting the ways that Postgres can expose data from outside of its default table structure context via these types of functions.
The killer reason for "Postgres as a platform" is that Postgres has a robust* security model (there are edge cases, but for a subset of statements, it works well)
That is true, and most DBAs are fully aware that the security model is only as good as the extensions they load and docker integration is very likely low on the list of necessities.
Aside - this is a great example that shows how bad Google search has become. Seeing only the comments here, I tried to search for "pgpodman" not realizing that it's from this very article. Google only returns stuff about podman. Searching for "postgres pgpodman" only gets articles about pgAdmin.
DuckDuckGo gets this article as the first hit - top 4-5 links are all relevant.
I think the use cases in this announcement are well-laid out. There's not _a ton_ that I think fits well for these container apps, but pganalyze or New Relic monitoring etc are great examples. Some of this stuff being just _a little bit easier_ to maintain and manage is a big help to smaller teams.
Thanks! There is definitely a full range, from being a "science project" running things like varnish or Redis from inside PG. The turnkey apps are maybe really easy and useful in certain cases. But you nailed it with some that are really just simple but practical like pganalyze. For us it's a lot of fun because you have practical, but then can do the absolute crazy things because sometimes software engineering should be fun.
CouchDB supports "select index.html && index.js from my_couchdb.some_app" so you can have a UI bundled with your DB Blob. Additionally, since the UI is "just some documents", technically they can update + sync to other distributed DB's.
It's a very interesting concept to make apps more cohesive by including (not just HTML+JS), but also a full docker container that could talk to the datastore w/o any intermediaries.
We're finally coming full circle with PHP5's bundling of SQLite, and are instead having Postgres effectively bundling PHP. :-P
Does this run the containers on the DB host itself? How’s that work with replication?
And what’s an actual end user application / use case for this? The post lists some examples but I don’t understand what it means to run them in a container on the DB.
Yes. I just dug deeper now and saw that you can get to the prices if you scroll to the right on mobile. It wasn’t obvious to me that there was more content to the right
* Use FDW connections to pull in data from all kinds of sources! Multiple databases, file formats, HTTP buckets, you name it!
* Custom behaviours in multiple languages! PL/Python, PL/Perl, PL/R!
* Read and write to web services! (PL/Python, pgsql-http)
* And now string together arbitrary containers! (pgpodman)
The way the extension system and the type system play together, it really is a very generic place to build weird integrated systems.