Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite the only database you will ever need in most cases (2021)

unixsheikh.com

Post reply on HN
Print view View original

141–150 of 378 posts

Re: SQLite the only database you will ever need in most cases (2021)

#141

Post by chillfox »

sanderjd wrote: post #102
danielmarkbruce wrote: post #62

Earlier quoted context omitted.

It's not sarcasm. The fact that it's a library and you point it at a file matters, and should be thought about. It implies that it's not built for distributed systems. It's not supposed to be a managed service. It's not a good option for what you appear to want. You deploy it as part of your application.. it's a library.

> It's not a good option for what you appear to want. Ok but the article you're replying in the comments to says "SQLite is all you need for nearly everything", and what the comment you're replying to is describing is, to use their very apt word choice, entirely ordinary . So how do we square this circle of somebody being told both "SQLite is all you need for everything" and "it is not a good option for your totally…

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.

Re: SQLite the only database you will ever need in most cases (2021)

#142

Post by christophilus »

bagels wrote: post #81
adamkf wrote: post #10

>The only time you need to consider a client-server setup is: Where you have multiple physical machines accessing the same database server over a network. In this setup you have a shared database between multiple clients. This caveat covers "most cases". If there's only a single machine, then any data stored is not durable. Additionally, to my knowledge SQLite doesn't have a solution for durability other than asynchr…

My standard for any serious service is at least minimal redundancy for improved availability during failures. At least two webservers.

I’m with you, but you could also make the case that most small web service businesses still run a single Postgres instance with no redundancy— just backups. So, you have a single point of failure. You can get quite decent uptime out of a single VPS.

Re: SQLite the only database you will ever need in most cases (2021)

#144

Post by kcb »

JohnBooty wrote: post #134
bogwog wrote: post #86

Earlier quoted context omitted.

> 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.

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. Yes. True. However, it is also true that we have a limited amount of time per week and a limited number of weeks on Earth. Time spent learning sysadmin-y stuff is less time spent mastering developer-y stuff. Think about what it means to be a "full stack" engineer in 2023: - Unix…

Unless you're one of the very few known as top in a field, mastery of a specific technology adds very little value and is always in danger of becoming more legacy than relevant. That's in comparison to someone with enough knowledge to assist in or handle any phase of getting a product into the the hands of customers and making money. Most things don't need master level work or knowledge to be successfully implemented.

Re: SQLite the only database you will ever need in most cases (2021)

#145

Post by bikamonki »

I have similar arguments for "Firebase is the only database you will ever need in most cases" for web apps, be it that you need real-time capabilities or not.

I can also confidently say: a static HTML landing page is the only website you will ever need in most cases. I suffer every time I see a one-page site, hardly ever updated, built with Wordpress. Why hire an 18-wheeler to deliver a pizza?

Re: SQLite the only database you will ever need in most cases (2021)

#146

Post by adolph »

irskep wrote: post #80
ericHosick wrote: post #67

Earlier quoted context omitted.

> Of course, you'll then end up paying $15+/mo for Postgres, which is hilarious for most hobby projects storing 50MB of data. Supabase ( https://supabase.com/pricing ) has an amazing free tier for PostgreSQL which gives you up to a 500MB database. Note: I'm not affiliated in any way with supabase.com.

Hey that's really cool, thanks! I'll consider adding a link to it in the repo. I'm a little skeptical that any given PostgreSQL free tier will stick around indefinitely, after what happened with Heroku. And once you hit 500MB, you jump immediately to $25/mo, so if you're running a hobby project, your choice is either to delete data or start paying $300/year. On the other hand, I'd expect a well-optimized read-heavy S…

Pocketbase may be a Supabase alternative for you then: https://www.programonaut.com/pocketbase-vs-supabase-an-in-de...

Fireship 3m video about Pocketbase: https://m.youtube.com/watch?v=Wqy3PBEglXQ

Re: SQLite the only database you will ever need in most cases (2021)

#147

Post by chillfox »

VintageCool wrote: post #107
chillfox wrote: post #76

Earlier quoted context omitted.

Most of the time people separate the app and database into two different VMs that the infrastructure team then runs on the same box. edit: This is done not because of any considered technical reasons, but because that's how one learned to deploy apps.

If you are running your webserver and your database on the same box, how are you big enough to have an infrastructure team?

Most organisations run a lot of server applications and most of them don't use much resources considering the size of servers these days.

Re: SQLite the only database you will ever need in most cases (2021)

#148

Post by irskep »

JohnBooty wrote: post #134
bogwog wrote: post #86

Earlier quoted context omitted.

> 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.

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. Yes. True. However, it is also true that we have a limited amount of time per week and a limited number of weeks on Earth. Time spent learning sysadmin-y stuff is less time spent mastering developer-y stuff. Think about what it means to be a "full stack" engineer in 2023: - Unix…

I really appreciate you taking the time to respond with these details. I do go deep on application-level tech (CSS, HTML, JS with and without frameworks, iOS dev, etc) and it's always disheartening for people to claim that choosing not to focus on specific technologies makes you a worse human being.

The other thing that's going completely over people's heads here is that I made this repo with the intent of helping other people who know less than me. I know I can figure out all the deployment bullshit, but I mentor folks who can't, and also don't have much money, and yet still need to deploy their portfolio projects to the Internet in order to find jobs. I was trying to find a balance of ease-of-maintenance vs monetary cost. If there's an even simpler solution with an even lower cost, that a random bootcamp grad could maintain, I'd adopt it in my template in a heartbeat.

If any of these people claiming it's easy want to work with me on a reboot of the "deploy a web site easy and cheap" template, I'd absolutely collaborate with them on it. I think it's important to democratize all the cheap computing power lying around these days.

Re: SQLite the only database you will ever need in most cases (2021)

#149

Post by tptacek »

bravura wrote: post #35

I would love to use SQLite for all my Django webapps that have only several simultaneous users, but this article suggests there are too many footguns for me to be able to do that. Is there a "using SQLite for a multi-threaded webapp for dummies" package that does all the config I need so I can just drop it in and go and not tune anything? Paging fly.io founders etc! If I have a persistent volume can my fly.io apps us…

You can certainly put a SQLite database on a Fly.io persistent volume. You can use Litestream to keep that SQLite database backed up, transaction-by-transaction, on other volumes or in S3; soon, you'll be able to use LiteFS to replicate that SQLite database as well.

Re: SQLite the only database you will ever need in most cases (2021)

#150

Post by sanderjd »

cldellow wrote: post #75
bravura wrote: post #61

Earlier quoted context omitted.

Thank you for the thoughtful response. I was looking at https://github.com/irskep/cheapo_website from commenter irskep above, and they make a nice point that render.com has automatic daily backups, solving 4) However, in another comment they mention "You can't(?) run migrations from another process" and that "people don't talk about the completely ordinary need to run migrations on a database". I guess this is also t…

You can run migrations from another process. Migrations are just writes, and SQLite supports writes from multiple processes. A single transaction that does a very large write will likely impact the reader -- the reader will be blocked while the write finishes. I use SQLite in a web scraper on my laptop. The scraper runs as 16 processes hammering the database, doing about 5,000 write transactions/sec. Occasionally, si…

> Migrations are just writes

It is possible to change the schema of a SQLite db as "just a write"?

Post reply on HN