281–290 of 378 posts
Why learn SQLite when you could just learn Postgres and have a database that is virtually guaranteed to be enough in almost all cases?
Earlier quoted context omitted.
If you install your own copy, you are on call for it, and the colo is unlikely to offer much help. You also have to set up monitoring or you won’t even know when it fails. Then there’s replication. Backups. All this stuff is work that PaaS vendors are ready to automate away, if my time is expensive for the org. For fun, sure, dink around and learn as long as there are no customers to affect.
Can’t you just run a script that sets all that up for you? Just like any other programming task?
Earlier quoted context omitted.
I think it's more that PaaS vendors aren't interested in first-class SQLite support when they can sell overpriced managed Postgres instead. Sure, it doesn't scale the same way, so it's hard to move upmarket and sell to Enterprise, but it's a shame that there's no one-click solution like there is for a managed database.
Let's say the following product existed: 1. You can only run one instance of your app. 2. There is a small window of downtime each deploy. 3. Your app has access to 10 GB of storage. The storage is persisted across deploys and can be used for sqlite. 4. Your sqlite data is automatically backed up and can be restored / downloaded as needed. How much per month would you pay for that product?
I'd find such a product really appealing, especially with a dedicated backup strategy that uses the SQLite backup API to do hourly snapshots or uses Litestream to S3 by default.
Earlier quoted context omitted.
Fair enough, but those things are unrelated to SQLite. Any app which uses a Postgres or MySQL PaaS would need to overcome the same hurdles. It'd be nice if those things were easier, but the SQLite part of it cannot be any simpler or easier than it already is. Backing up SQLite can be done with a 2 line shell script ssh vm 'sqlite3 my_database.db ".backup my_database.db.bak"' scp vm:my_database.db.bak .
That's true, but previously the PaaSs I've looked at didn't seem to have the same concept of persistent volumes, or maybe they were costly, I forget. In any case, I tried on Heroku before, and one other provider, and they didn't really support this use case, or pushed you to use their hosted PostgreSQL offerings, which were expensive (for my budget). Fly.io looks a lot simpler and cheaper! Your backup script is basic…
For use cases similar to yours, I'd probably bite the bullet with a raw VM from somewhere and manually configure systemd and Caddy on it and manually upgrade Caddy on it from time to time. We would probably get a re-usable Caddyfile and systemd unit from this initial setup, making it even easier to change VMs later if needed.
It's so simple, it doesn't need a PaaS.
I really appreciate all your replies and sharing your experiences. It's helping me think through deploying my own side projects which, you guessed it, will use Caddy and systemd on a VM somewhere.
This sentiment pops up regularly on HN, and I've seen at least one article per month for the past few months, but the trouble is, none of them seem to help you actually deploy it. They assume you're comfortable spinning up public web servers. If you want to use a PaaS to deploy an app, because you don't want to spend your time learning to be a sysadmin, then all the tutorials are going to put you on the Postgres path…
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-) Sorry, but that's a terrible attitude to have. You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer.
Why make Docker and essential part of a system before you actually need it? There’s a reasonable chance that you never need it. I know this, because a lot of business and hobby systems have been in operation since before Docker existed.
Docker has value in many cases, but it certainly doesn’t have to be a necessity.
Earlier quoted context omitted.
Most things don't need zero downtime deployment. Now it's nice to have and might be an interesting technical challenge to solve, but it's usually not strictly needed. edit: when I worked as a sysadmin we would have to schedule outages for updating apps that were designed for zero downtime anyways because those were the processes of the organisation.
Yeah I've realized this is just a disagreement over the word "most" which won't really be resolvable empirically. It doesn't fit my experience that most applications are single node with lax uptime and failover requirements.
This sentiment pops up regularly on HN, and I've seen at least one article per month for the past few months, but the trouble is, none of them seem to help you actually deploy it. They assume you're comfortable spinning up public web servers. If you want to use a PaaS to deploy an app, because you don't want to spend your time learning to be a sysadmin, then all the tutorials are going to put you on the Postgres path…
I'd argue you should be.
I'm currently learning a low level language. It has nothing to do with my job, will not directly be a benefit to my work, and won't look good on my C.V.
It will (and has) _indirectly_ improved my work, because I have a better understanding of why certain things higher up are the way they are, which allows me to make better decisions.
You can ignore everything that's not "your area", whatever that might be, but I'm my opinion it means you'll be stuck at a certain invisible level because of it.
Earlier quoted context omitted.
Most business have daily downtime where the entire business is closed as in not business hours. Being sensitive to downtime is more common for companies that has some kind of online service as their primary product, but most companies are not online companies, or even global companies with offices across all the time zones. Even for online business some downtime might be acceptable or even preferred. I used to work f…
scheduled maintenance downtime at night != unplanned failure downtime at random time
Earlier quoted context omitted.
Let's say the following product existed: 1. You can only run one instance of your app. 2. There is a small window of downtime each deploy. 3. Your app has access to 10 GB of storage. The storage is persisted across deploys and can be used for sqlite. 4. Your sqlite data is automatically backed up and can be restored / downloaded as needed. How much per month would you pay for that product?
Interesting question. I think you could probably get those features by deploying Piku or Dokku for like $4/mo on a VPS, and the equivalent managed Postgres on Render would be like $20/mo (16GB SSD), so something like $6-10 seems like the right range to me. Maybe not a booming business, but a nice margin percentage and worth paying for good UX. And the cheap version doesn't need to be the only version if people want m…