Live data from Hacker News

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

unixsheikh.com

191–200 of 378 posts

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

#191
post #29

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…

Note with Neon now you don't need to spend $15+/mo for Postgres because they separate compute from storage. So compute can scale down to 0 and storage is cheap.

Neon only recently entered public preview and I am unable to find any pricing information.

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

#192
post #181
post #103

Earlier quoted context omitted.

Well, he did cherry-pick one joking comment out of a well-intentioned post in order to say I have a bad attitude, so that's not exactly welcoming. And very patronizing, considering I have actually done that kind of work with Salt Stack a few years ago, and just don't want to bother with it at the moment because I have other priorities. I learn new things every day, and one day, Docker was that thing. I am now better…

Sure, that comment came a bit rough. But I'm not even sure it was triggered by the Docker comment, rather than the developer/release engineer opposition. At least that's how I see it. And maybe I just don't see the added value of PaaS because I've been spinning up public web servers for too long now ;-)

Yeah, that's fair, and it was bad phrasing on my part. The engineer type distinctions are completely imaginary. It just really threw me off to have people respond to me sharing something I thought was helpful with claims that I'm somehow opposed to learning, when this project is nothing but learning.

I do think people who have experience deploying software have a blind spot here, just like I have a blind spot for people who have never learned how to center a div. jUsT uSe FlExBoX

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

#193
post #132

Earlier quoted context omitted.

>learning these things will make you a better developer. Of webapps. Will make you a better developer of webapps. It may surprise you to learn that there are more kinds of software than that. Sometimes the final product is something like a binary that runs outside the browser, and deployment is no more complex that putting an tar.gz'd executable on a website.

I'm not sure what that has to do with sqlite. I'm very much a non-web-developer, I never use Docker and "deployments" and stuff, but sqlite is absolutely trivial to install and run, and use for non-webapp stuff? Even operating system components use it.

That's my point. Everyone is assuming web app.

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

#194
post #151

Earlier quoted context omitted.

Fwiw, I’ve used all of those in my career, extensively here and there. I’ve written many thousands of lines of bash scripts. Even written my own php-for-bash-script style code tags that support arbitrary shells. I’ve written my own log based distributed kv store, gone down the YouTube trail of writing my own db, gone through the angular and react iterations, deep dove in docker, docker compose, k8s, crds and custom h…

Maybe he wants to spend more of his time with his wife and floating point child.

My floating point children give me so much grief, they are all so irrational.

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

#195
post #29

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…

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

One significant caveat: "Free projects are paused after 1 week of inactivity." I'm not complaining, but I reckon a lot of hobby projects would see sporadic activity. For example, I used to upload a list of my CDs to a VPS, so that when I found something interesting at a music store, I could check to see whether I already own it (#FirstWorldProblems).

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

#196
post #29

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…

Why do people use hosted databases instead of just installing them? I don’t understand it.

Because operating a database sucks.

Specifically: setting up database replication sucks, setting up failover sucks, setting up backups sucks (even with a PaaS you need to do this, but you can use it as your first layer), migrating database clusters to new versions or hosts sucks, keeping your host's software up to date sucks, and setting up alerting and monitoring sucks.

It's easy to get an open port to connect to, but hard to keep it there for five years.

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

#197
post #86
post #29

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.

One consideration for small vendors who target mid-market or larger customer segments is Vendor Risk Management assessments. These typically dive into resilience (among other things) along with roles and responsibilities. If it's running on a PaaS a good chunk of responsibility can be delegated under the shared responsibility model.

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

#198

I like sqlite as much as the next guy but it's built-in datatypes are limited. Things like arrays, UUIDs, geometry stuff, JSON, etc. Sure you can store more advanced stuff as blobs or text but then you have to mess around with deserializing it in the host language and you lose the ability to query it directly in the db engine.

add partitioning and sharding, basic search in other DBs is pretty nice as well. I've come in on a project where the team did custom trig for distance queries that took 30 seconds to run once the data grew past their data set. All so they could use sqllite for local development. :facepalm:

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

#199
post #151

Earlier quoted context omitted.

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…

Fwiw, I’ve used all of those in my career, extensively here and there. I’ve written many thousands of lines of bash scripts. Even written my own php-for-bash-script style code tags that support arbitrary shells. I’ve written my own log based distributed kv store, gone down the YouTube trail of writing my own db, gone through the angular and react iterations, deep dove in docker, docker compose, k8s, crds and custom h…

I've dabbled in the whole stack as you've said. I've written a web framework, done some Docker, done some fun Javascript demos, shipped web and desktop code in a bunch of languages. Built and maintained my own physical servers back when that was a thing people did. Windows, Linux. Currently relearning C and 68K game development (at a glacial pace) as a side project. Did assembly language in college.

Ran a business. Did everything from building the servers, the code, the marketing, the design, community management, merch, and event planning. Call it "ultra full stack," maybe?

So yeah, it's extremely possible.

But I'll also tell you bluntly I was only really good at a few of those things. Most of those things, I was bad at or perhaps more accurately I just acquired the bare minimal knowledge to get by in my specific and limited use cases.

And many of those skills decayed quickly. I knew a thing or two about SEO and front end development in let's say 2000-2012 but those fields change fast and little I knew back then is relevant now.

That's why I say that in 2023, I think the notion of "full stack developer" has grown untenable. You cannot be good (in the sense of shipping actual maintainable and performant production level stuff) at the entire stack simultaneously now that complexity at each level of the stack has multiplied relative to 2005 or 2015. For example, your own db -- is that a fun (and impressive!) hobby project or is that really production level stuff?

To be ultra clear, I am not knocking what you have achieved. It sounds awesome and I suspect you have dived deeper into more things than I. Kudos, and I mean that sincerely.

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

#200
and if you need to migrate your database schema in any non-trivial way.....well then you're on your own. for anything beyond adding a column to a table, you'll have to copy the whole table to a new one with the structure you want, drop the old table, then rename your new table, carrying along all the foreign key constraints and other constraints while you do so. Or use a tool which does this (I write one such tool and it's not fun to maintain).

if SQLite allowed for custom commands, at least there could be ALTER commands that run this process behind the scenes, which the SQLite developers wouldn't have to maintain.

Post reply on HN