Built-in Litestream replication and automatic restore is a new feature I added in OpenRun (a self-hosted deployment platform for web apps). Apps can use SQLite with zero code changes while OpenRun handles backup/recovery. This works on a single node with Docker/Podman and also on Kubernetes.
Do you have any mechanisms in place to prevent two separate instances of OpenRun that share the same configuration from corrupting their shared S3 Litestream store?
That comment was about what happens during an app deployment, to avoid multiple pods on Kubernetes from writing to the same volume. Multiple apps on one OpenRun have no issues, the replication will be identify them as different.
If by mistake you actually have two separate instances of OpenRun pointing to the same S3 volume and path_prefix (with single-node Docker or with Kubernetes), the generated S3 paths have an binding ID which should be unique across instances. I will check whether there is anything more which can be done to prevent any issues with such an incorrect config.
I use the same stack to run my apps! sqlite as Database backen on ephemeral pods. On initialisation, the pod restores the current litestream backup from object storage. No persistent volumes needed. No issues so far.
Without persistent volumes, every deployment of the app may require the SQLite data to be restored from S3, which can take time if database size is large. With PVC, regular app deployments use existing database, only a disaster recovery scenario restores from S3.
Yes, it feels magical to just recreate your namespace or even create a new K8s cluster and see all your apps (from OpenRun metadata) and app data restored automatically.
It's classic HN to criticize OP that their solution doesn't scale, and then for OP to respond by saying that they don't need the scale and anyway PG tells you to do things that don't scale.
SQLite is great for small-production scale. Don't let anyone tell you different. Just keep in mind that it's a pain to move if you ever do need to scale up. If it's a startup, you might. If it's a weekend hobby project you're building for your personal use only, you probably won't.
On Kubernetes, for apps using SQLite, maxReplicas is set to 1 and OpenRun uses the Recreate update strategy. This ensures at most one pod is active (requests are queued until the new pod is healthy). There should never be more than one pod accessing the SQLite database.
Built-in Litestream replication and automatic restore is a new feature I added in OpenRun (a self-hosted deployment platform for web apps). Apps can use SQLite with zero code changes while OpenRun handles backup/recovery. This works on a single node with Docker/Podman and also on Kubernetes.
Do you have any mechanisms in place to prevent two separate instances of OpenRun that share the same configuration from corrupting their shared S3 Litestream store?
UPDATE: Looks like you answered that here already: https://news.ycombinator.com/item?id=49502025
That comment was about what happens during an app deployment, to avoid multiple pods on Kubernetes from writing to the same volume. Multiple apps on one OpenRun have no issues, the replication will be identify them as different.
If by mistake you actually have two separate instances of OpenRun pointing to the same S3 volume and path_prefix (with single-node Docker or with Kubernetes), the generated S3 paths have an binding ID which should be unique across instances. I will check whether there is anything more which can be done to prevent any issues with such an incorrect config.
I use the same stack to run my apps! sqlite as Database backen on ephemeral pods. On initialisation, the pod restores the current litestream backup from object storage. No persistent volumes needed. No issues so far.
Without persistent volumes, every deployment of the app may require the SQLite data to be restored from S3, which can take time if database size is large. With PVC, regular app deployments use existing database, only a disaster recovery scenario restores from S3.
Yes, it feels magical to just recreate your namespace or even create a new K8s cluster and see all your apps (from OpenRun metadata) and app data restored automatically.
I have no use case where I store a TB of data in a sqlite let alone few GB. Currently this checks out and restore is few seconds.
It's classic HN to criticize OP that their solution doesn't scale, and then for OP to respond by saying that they don't need the scale and anyway PG tells you to do things that don't scale.
SQLite is great for small-production scale. Don't let anyone tell you different. Just keep in mind that it's a pain to move if you ever do need to scale up. If it's a startup, you might. If it's a weekend hobby project you're building for your personal use only, you probably won't.
[flagged]
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
This was flagged so I think I am vindicated.
Do you have a particular issue with... the company that wrote this post, their choice of DB, decisions made in Litestream, SQLite, etc.?
Oh you aren't generally interested in running MySql apps on VMWare ESX ARM servers hosted in France?
The fact that this made it to the main page is either some kind of coordinated effort or bots.
Not a company :-) OpenRun has been a passion project I have been building for last three years, trying to make declarative deployments easier
[flagged]
On Kubernetes, for apps using SQLite, maxReplicas is set to 1 and OpenRun uses the Recreate update strategy. This ensures at most one pod is active (requests are queued until the new pod is healthy). There should never be more than one pod accessing the SQLite database.
GP is an llm