Announcing Postgres Container Apps: Easy Deploy Postgres Apps
Today, I'm excited to announce the public beta of Postgres Container Apps for your Postgres databases on Crunchy Bridge. With Postgres Container Apps you can, from directly inside Postgres with a simple function call, spin up a container that is running right alongside your Postgres database. Let's take an immediate look of how we can spin up a Postgres featureserv:
CREATE EXTENSION pgpodman;
CREATE EXTENSION postgis();
SELECT run_container('-dt -p 5435:7800/tcp -e DATABASE_URL=<DATABASE_URL> docker.io/pramsey/pg_featureserv:latest');
It's as simple as that, and now I can connect directly to my pg_featureserv at: http://p.3fqs3ruv2vfq3malzedvtog4xq.db.postgresbridge.com:5435/. Or more interestingly with it here is all mountains within 100km of Seattle.
If you're anything like those who got early preview access you may be thinking "Cool, but why?"
There are a few great use cases we're excited for actually:
- 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)
Container apps is powered by the Crunchy Data built pgpodman extension. With pgpodman you can:
- Start a container with
SELECT run_container('<container command>'); - List all containers with
SELECT list_containers(); - See the logs of a container
SELECT container_logs('<container_id>'); - Stop a container
SELECT stop_container('<container_id>');
If you're curious to get started, feel free to jump over to Crunchy Bridge and give it a try or take a look at the docs. Otherwise, feel free to read on to get a feel for some of the use cases that container apps is a great fit for.
In the early development of Postgres Container Apps we worked with a few launch partners, to ensure we've got as smooth a developer experience as we can create. Let's drill into two great examples.
Dead simple Postgres monitoring
Crunchy Bridge does a lot for you in keeping your database healthy and active, but there are a lot of monitoring tools that help you go deeper. We often get requests similar to, "How do I monitor my database with New Relic?" One tool we love is pganalyze as it's specialized just for Postgres. Here's what founder of pganalyze, Lukas Fittl, had to say:
"Crunchy Bridge is what Postgres-as-a-Service is meant to be. With Postgres Container Apps, we were able to enable full pganalyze functionality including Automatic EXPLAIN and the pganalyze Index Advisor with ease, through a one-click deployment step."
Pganalyze updated their container to be specially designed for Postgres Container Apps to give what may be the easiest enhanced Postgres monitoring story that now exists.
When you setup the pganalyze container you'll immediately be getting:
- Drill-down into historic query performance
- Automatic EXPLAIN plans through auto_explain
- Missing index recommendations with Index Advisor
- Log monitoring with predefined filters
And it's literally a single command inside your database.
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.
Once we've got an instance provisioned starting Hasura with Postgres Container Apps is as simply as:
SELECT run_container('-dt -p 5434:8080/tcp -e HASURA_GRAPHQL_DATABASE_URL="<DATABASE_URL>" docker.io/hasura/graphql-engine');
And with that I have an up and running Hasura serving up a GraphQL on top of my database:
http://p.v5etllz4eng6bgw4646o3yy3om.db.postgresbridge.com:5434/console
Why not run the app on another server?
First, let's get this out of the way – container apps is not a full fledged PaaS replacement. Many web apps have a need for scaling equally as much as the database, and in those cases Crunchy Bridge is a great answer for your database side while leveraging something like Fly.io or Heroku for the application. But, not all "apps" need to handle large scale... Sometimes your database is the real app and is doing the heavy lifting. Sometimes you just need to get started quickly and you'll scale the web app later. Sometimes you want one less server to manage and monitor.
So, what are some great examples for container apps?
In the past few years more and more tools built especially for Postgres have emerged. Many of these are APIs out of the box that let you start building against PostgreSQL almost immediately. In that category here are just a few that are our favorite to run inside container apps:
Database Admin and Browser Apps
Another category is when you want a tool to interact with your database. I'm a big fan of psql myself, but that isn't for everyone some folks want a graphical interface to browse their schemas and query data. Sometimes there is a need for defining queries and sharing with other non-technical folks. Just a few of our favorites include:
Database monitoring tools for Postgres
Postgres is a great database that comes with a lot of built-in insights such as pg_stat_statements, pg_stat_activity, pg_proctab. But sometimes you want more, tools like pganalyze, New Relic, and Datadog are a common go to for monitoring the full performance of your database from more system level metrics like i/o and memory usage, to Postgres specific things like slow queries. With Postgres Container Apps you can easily run a sidecar agent to get the full insights you need with ease.
What else?
And finally, our favorite category of things you can run with container apps: the crazy ideas. We don't know what will actually happen in this category. The very first thing we tried was booting Redis from inside Postgres, and guess what? It worked. If you need a lightweight cache to run right along side, 1 command and you have a Redis cache, connect it with the Redis foreign data wrapper for Postgres and you're off and running. Our own @pwramsey once he got pg_tileserv running decided he needed a Varnish cache in front of it. All it took was:
SELECT run_container('-dt -p 5435:6081/tcp -e BACKENDS=p.3bei7nueizcwbkh467ilrct3ti.postgresbridge.com:5434 -e DNS_ENABLED=false -e COOKIES=true -e PARAM_VALUE="-p default_ttl=3600" docker.io/eeacms/varnish:latest');
Today we're excited to make this available on Crunchy Bridge in public beta, but we're also curious on what you think–let us know your opinion @crunchydata.
