Live data from Hacker News

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

unixsheikh.com

121–130 of 378 posts

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

#121

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…

Distributed databases are rarely needed. I wouldn't call it an ordinary use case. The article isn't claiming Elon Musk can run Twitter off SQlite

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

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

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

#123
post #58

We should teach SQL in high school

And scripting. Most white collar jobs these days involve software, so most white collar jobs probably would benefit from being able to script.

I partially agree, but then I remember my high school IT lessons, where people in my class (our profile was math and IT, mind you) struggled with excel and very basic programming. Scripting may sound trivial for people reading HN, but certainly is not for everyone.

Not to mention that to really benefit from scripting you need programs that you can actually execute. As far as I know Windows (which most people use) is not very friendly in that regard. Powershell improves things a bit, but I'm pretty sure you can't just manipulate .xlsx files with a simple shell script on Windows, and this is one of the lowest hanging fruits I could imagine for white collar workers.

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

#124
post #109
post #96

Earlier quoted context omitted.

I don't know why this is downvoted, it's probably the best advice on this page. Learning a few things about deployment definitely helps to make better software.

Agreed. Too much reliance on AWS, Heroku etc. can leave you without vital Linux skills. Linux cli tools are not just for getting a job done, though they're great at what they do. No, they're part of the *nix culture which is what open source software is based on. Only recently have I become aware that it was better to have entered software development in or before the early 2000s, ie. before The Cloud took off. You w…

I used slackware linux. I wrote assembly code when I was a teenager. I use 'perl -i -pe' constantly. I still don't want to learn a bunch of arcane flags from a bunch of tools with a million gotchas. Sorry. I'd rather focus on the code craft that gives me joy these days.

Sorry, I detest this attitude of: "Well I was hazed so why aren't you hazed too?"

Did I mention that Russ Cox and I used to write C code with pen and paper? https://news.ycombinator.com/item?id=32874759 If you haven't, are you even qualified to discuss what vital skills others are missing?

Or maybe because I learned perl because it was simpler than tr and awk, I should STFU? Give me a break.

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

#125
post #17
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…

people have been providing acid transaction semantics on single machines for 50 years do you think ims/db ran on a cluster the d in acid stands for durability you're talking about pitr, which is what mysql semi-sync provides (and afaik you are correct that sqlite doesn't offer pitr)

Sounds like IMS runs on Z system mainframes with redundant hot-swappable CPUs and memory. They pay IBM a lot of money for the illusion of a single reliable machine, when a different OS would manage it as a small cluster.

We economize by using racks of cheap, flaky commodity hardware, but we have to be ready for one computer to die by failing each application over to another.

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

#126
post #38

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.

The biggest one missing is date and/or time. The workarounds all suck: - Store the date as a huge, wasteful string in ISO8601 format - Store it as Unix epoch seconds - Store it as a fractional Julian day Besides the first one, you have to remember how the date is stored and ensure all client libraries handle the conversion. If you want to view or manipulate the latter 2 formats in SQL, you need to chain a bunch of co…

> Store it as Unix epoch seconds

This is what we do. Have been storing 100% of our timestamps this way in SQLite for ~8 years now. Using .NET to handle the actual conversion to/from long.

  var myTimeUtc = DateTime.UtcNow;
  var myTimeUnix = new DateTimeOffset(myTimeUtc).ToUnixTimeSeconds();
  var myTimeUtc2 = DateTimeOffset.FromUnixTimeSeconds(myTimeUnix).UtcDateTime;
No drama at all. No weird libraries or utility methods. It's all simple built-ins these days.

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

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

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

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

#128
post #98
post #80

Earlier quoted context omitted.

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…

PasS my ass. What's so difficult about setting up a VPS and installing PostgreSQL, MySQL or whatever floats your boat? At Hetzner.com (no I don't work for them) you can get a dual-CPU VPS with 4Gb RAM, 40Gb SSD and 20TB traffic. That'll get you off to the races with Spring Boot and PostgreSQL if you limit the JVM to half the available RAM. For something like Rails, Laravel or Express even easier.

By doing so, I am a failure, and whatever I'm doing is not worthwhile because installing PostgreSQL on my $20 VPS means I cannot possibly achieve /Google/Facebook/Amazon/ scale.

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

#129
post #28

> 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. Am I misunderstanding this or is this not the vast, vast majority of all cases?

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.

That would never fly in production for any sort of enterprise application with uptime requirements.

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

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

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

This whole conversation is about using SQLite on web servers, so I think it's reasonable for OP to assume that's what we're talking about.
Post reply on HN