logpaste VS node-pg-migrate

FWIW, I've used Litestream on Google Cloud Run and never run into issues, but I haven't pushed it much:

https://github.com/mtlynch/logpaste/blob/master/docs/deploym...

Currently, no. I've implemented that functionality recently in my other tool, LogPaste, so it shouldn't be too hard to reproduce here.

My tool is called LogPaste. It allows users to generate shareable URLs for text files. I use it in my open-source KVM over IP device so that users can easily share diagnostic logs with me.

I designed it with self-hosting in mind, so there are instructions for hosting it under Docker, as well as with several free cloud hosting providers. You can even host the data storage part yourself if you use a solution like Minio.

I still use GCP, but I avoid locking myself into their proprietary infrastructure when I'm writing new stuff. I feel like Google is far too cavalier about deprecating services and forcing their customers to do migration work.

It is hard to replace GCP's managed datastores because I really don't want to maintain my own database server (even if it's a managed service that someone else upgrades for me). So I've stuck to Google Cloud Datastore / Firestore, but I've been experimenting a lot with Litestream[0], and I think that might be my go-to choice in the future instead of proprietary managed datastores.

Litestream continuously streams data from a SQLite database to an S3 backend. It means that you can design your app to use SQLite and then sync the database to any S3 provider. I designed a simple pastebin clone on top of Litestream, and I use it in production for my open source KVM over IP. It's worked great so far, though I'm admittedly putting a pretty gentle workload on it (a handful of requests per day).

[0] https://litestream.io/

[1] https://github.com/mtlynch/logpaste

Why PG? For the clarity of the article to a large circle of developers, the entire explanation will be built by PostgreSQL and PG package. And in a real project, the database schema will change over time, and in order to be able to perform migrations, we will use Node PG migrate.

b) How you will manage schema migrations: every time you change tables, columns, foreign keys, every time you create or modify stored procedures, and so on, you need to do this through a migration. Here I'm at loss to recommend anything specific, but if you went with Prisma, I would read their docs and use whatever they are recommending you (if they actually recommend something). If you want something more neutral but still in the node ecosystem, node-pg-migrate might be the winner here? I'm not sure.

You’ll probably want something like this too: https://github.com/salsita/node-pg-migrate

You can use any normal DB migration tool. For k8s, I put the app's readiness probe to false, run the migrations and then toggle the probe back to true.

Here are some migration libraries:

Go - https://github.com/golang-migrate/migrate

Node - https://github.com/salsita/node-pg-migrate