On Postgres Container Apps. Behold Smooshing: database meet app platform, app platform meet database.

Today Crunchy Data launched Postgres Container Apps, a neat idea that pretty much turns the current model for database and app runtime on its head. Container Apps do what they say on the tin – you can run apps in containers alongside Postgres. This isn’t some big Kubernetes stateful apps monstrous architecture, but rather a simple way for developers to build and run apps quickly. It’s like functions, runners, containers as sidecars for Postgres. You can run and manage the container from Postgres, and, say query container logs from the database.

As Craig Kerstiens, who runs cloud product stuff at Crunchy, puts it:

Postgres Container Apps: With a single command you can launch a container from inside Postgres.

From the launch page, here are a few use cases:

• Turnkey APIs that sit on top of a Postgres database (examples such as Hasura, PostgREST, Postgraphile, Pg_tileserv, Pg_featureserv)
• Turnkey admin/data management and reporting tools (examples such as Pgweb, PgHero, Blazer)
• Running monitoring agents for extra visibility into your database (examples such as pganalyze, New Relic, Datadog)

I really like the API story.

How about an API for your database?
Building an app and starting with the schema first? Want to expose that to your frontend developers, enter Hasura. Hasura provides an instant GraphQL API over all your data, which makes it easy to prototype and build apps faster. When the time comes to scale your Hasura app we recommend taking a look at fully managed Hasura, but starting with Crunchy Bridge then plugging it into Hasura.io later is trivial.

So. Running Containers from SQL. What could possibly go wrong? Quite a lot obviously – security-focused people and database purists will get migraines just thinking about the model. There will be much eye twitching. But from a playful, productive, developer experience perspective it makes a lot of sense. The Hasura example makes clear why. Great for API prototyping. But also just interesting In some weird ways. One of the first things a Crunchy engineer did was spin up a Redis instance as a Postgres Container App.

If you need a lightweight cache to run right alongside, 1 command and you have a Redis cache, connect it with the Redis foreign data wrapper for Postgres and you’re off and running.

One reason I was so intrigued when Craig pinged me about it a week or so ago was that Stephen had just written a really thought-provoking piece about database and app platform convergence – Vertical Integration: The Collision of App Platforms and Database.

There are already too many primitives for engineers to deeply understand and manage them all, and more arrive by the day. And even if that were not the case, there is too little upside for the overwhelming majority of organizations to select, implement, integrate, operate and secure every last component or service. Time spent managing enterprise infrastructure minutiae is time not spent building out its own business.

What this means in practice is previously distinct categories of software are increasingly likely to be collapsed, as we’ve speculated about and have subsequently seen with CDNs and general purpose clouds as but one example. Given the fact that most application platforms will require a database and most database platforms will be backing applications, the clear implication is that application platforms should be eyeing database vendors with an eye towards acquisition, and that database vendors should be considering application platforms for the same reason.

The market is driving players at both ends of the spectrum towards vertical integration, in other words. Not that the concept is new, to be clear: Heroku, for one, has offered a combination of the two for fifteen years, and never quite managed to hit mainstream acceptance.

It may or may not be a coincidence (it isn’t) that Craig worked at Heroku, and knows as much about managed Postgres as anyone on the planet, that the tool is coming from Crunchy Data.

Postgres Container Apps is a great example meanwhile of what we at RedMonk call “smooshing”.

“Smooshing” is the officially recognised RedMonk technical term for the phenomenon of software and systems categories overlapping, converging, fragmenting, coalescing, re-coalescing in new forms, maybe turning a little bit cloudy and vaporous every now, adjacent markets rubbing up against one another and leading to new forms, platforms and approaches.

Smooshing is really the history of the industry. We see waves of technological invention break and fragment onto the shores of the adoption landscape. The Cambrian explosion pattern of IT. That is innovation.

Over time, an understanding arises about what the packaging exercise should be, at what layer of the stack we should start simplifying things so the user can adopt the new technology more easily.

At the moment Postgres Container Apps is a neat hack that will enable neat hacks. I can imagine for example Simon Willinson building something cool with it, say with his Django SQL Dashboard., “an interface for running arbitrary read-only SQL queries directly against a PostgreSQL database, protected by the Django authentication scheme”.
A couple of things in conclusion.

Firstly Container Apps is not currently open source technology. That will limit adoption to Crunchy Data users, which is perfectly reasonable at this point in its lifecycle, which may hamper adoption among some potential user bases, but not among those that like to play with new things. As a business model emerges we may see code contributed to Postgres, but this is of course the age of the managed service.

Secondly I think it’s great to see some simple container innovation, rather than everything being Kubernetes focused. Docker began life as a tool that just made developers’ lives easier. There is more to containers than K8s. So this is a nice innovation branch, simple containers if you like, interesting smooshing, and I look forward to seeing what kind of hacks people build with it.

I will leave the last word to Craig though, in his tweet from late last year

Broadly better DX for your database is possible.

And it’ll be here sooner than you think.

It doesn’t take throwing out decades of database development, it just takes building a bridge to both sides, stay tuned.

Disclosure: Crunchy Data, Hasura and Salesforce are clients. Other named vendors are not.