Live data from Hacker News

SQLite Is Serverless

sqlite.org

161–170 of 453 posts

Re: SQLite Is Serverless

#161

Does this mean that you can hack some database storage (w/ sqlite) together on frontend only hosting platforms like Github or Netlify? I think not, but I wonder if some hack is available by virtue of it simply being a file that you can read (and somehow) write to. The best I came up with: let's say you have a toy project, and you call the Github API and replace the file upon every write. Implementing a read is easier…

> Does this mean that you can hack some database storage (w/ sqlite) together on frontend only hosting platforms like Github or Netlify?

The meaning of that 'serverless' and this 'serverless' is incompatible, since the web inherently needs servers.

I think the best you can do is uploading the SQLite file to a static hosting platform & decoding it in the browser. You can then use it as a file storage with DB capabilities. (Which is what basically really SQLite is.)

Re: SQLite Is Serverless

#162
post #149

I love SQLite, but people approach it from a classic RDBMS angle which confuses them. Here's the deal: SQLite is a file format with a nice API that uses SQL as the paradigm for reading/writing to the file. That's it. Stop overthinking it. Can you write a microservice that stores its data in a big JSON file that you've built some code around to read/write to? Yes. It's just a file, but you have to build all the read/w…

I'm not sure I understand your comment. What's the signifigance of it being "just a file format"? What are the aspects of "approaching it from a classic RDBMS angle" that are incompatible with it being "just a file format"? I've always seen it as "just a file format" myself, and I think I've always approached it "from a classic RDBMS angle", but I've never felt confused, and I don't see what I'm overcomplicating.

If you are not confused, this might be an indication that the comment will not provide any new information for you. If the comment provided no new information to you, it might be an indication you're not confused (and it was therefore not farted in your general direction)

Re: SQLite Is Serverless

#163
post #24

a bit tangential, but when do you move form using in-application data structures (maps, trees, vector/arrays) to using a database? Is it basically when the data doesn't fit in memory? I've been programming for almost a decade and I've never come across needing a database... (for context, it's ten years without anything web related) I'm interested in them and I'd love to learn SQL but I can't even think of a use case…

How do you persist state across a restart of the app or device? Do you dump state to a file? Do you not need to persist state ever in 10 years of software development?

Re: SQLite Is Serverless

#164
post #149

I love SQLite, but people approach it from a classic RDBMS angle which confuses them. Here's the deal: SQLite is a file format with a nice API that uses SQL as the paradigm for reading/writing to the file. That's it. Stop overthinking it. Can you write a microservice that stores its data in a big JSON file that you've built some code around to read/write to? Yes. It's just a file, but you have to build all the read/w…

I'm not sure I understand your comment. What's the signifigance of it being "just a file format"? What are the aspects of "approaching it from a classic RDBMS angle" that are incompatible with it being "just a file format"? I've always seen it as "just a file format" myself, and I think I've always approached it "from a classic RDBMS angle", but I've never felt confused, and I don't see what I'm overcomplicating.

> and I think I've always approached it "from a classic RDBMS angle"

Have you tried to figure out where to install the server or asked what the system requirements were for it?

Have you grown concerned that once the system moves into production the O&M team won't know how to operate "yet another database"?

Do you spend agonizing hours trying to figure out if it supports multithreaded connection pools for multi-user writes?

Have you wondered if your organization has the budget to add another DBA to the team if you add SQLite to your tech stack?

If the answer is no to all of the above you aren't approaching it from a classic RDBMS angle. Believe it or not, there are tens of thousands of questions about SQLite struggling to figure out the answer to the above questions.

The people asking these questions are not stupid, they're just approaching the technology from the wrong direction.

This post is no different than "CSV is serverless" or "JSON is server-less" with a blog post about classic vs neo-serverless JSON technologies.

Re: SQLite Is Serverless

#165
post #149

I love SQLite, but people approach it from a classic RDBMS angle which confuses them. Here's the deal: SQLite is a file format with a nice API that uses SQL as the paradigm for reading/writing to the file. That's it. Stop overthinking it. Can you write a microservice that stores its data in a big JSON file that you've built some code around to read/write to? Yes. It's just a file, but you have to build all the read/w…

I'm no SQLite expert but by this logic aren't all single-host databases that tick the "Durability" ACID checkbox "just file formats" in the sense that yeah, the bytes we care about exist somewhere in the filesystem?

Moreover I'm having trouble coming up with things that I'd associate with a RDBMS and not "just a file format" that SQLite doesn't support. Transactions? SQLite has them. Relational constraints? SQLite has those too. Could you elaborate on some of the confusion that you've seen around this?

Re: SQLite Is Serverless

#166
What I really want: SQLite storage backend driver for s3/gcs. No need for disks then. I haven’t been able to find such a solution though; and am not technically proficient enough in C (the Lang SQLite is written in) to do so myself.

Re: SQLite Is Serverless

#168
post #149

I love SQLite, but people approach it from a classic RDBMS angle which confuses them. Here's the deal: SQLite is a file format with a nice API that uses SQL as the paradigm for reading/writing to the file. That's it. Stop overthinking it. Can you write a microservice that stores its data in a big JSON file that you've built some code around to read/write to? Yes. It's just a file, but you have to build all the read/w…

I think most rmdbs systems are just a file (or set of distributed files) when you strip away all the helper functions. The fact that Sqlite squirrels everything into a single archive doesn't mean many of the abilities housed within a more comprehensive database aren't there. You can implement JSON columns and full text searching and numerous other fancy systems.

The main argument I hear for why Sqlite deserves second class status in the DB marketplace is the difficulty in handling multiple writes simultaneously.

To that point I'd say it's more of a simplicity in design choice. Search for 'DB race conditions' and you'll see that every database struggles with handling multiple writes nested inside complex transactions. Sqlite avoids the whole mess and requires the programmer to think through I/O instead of offloading all that logic to the rdbms software.

Re: SQLite Is Serverless

#169

Earlier quoted context omitted.

You could make it persist if you have it uploaded somewhere. But then I guess thats not serverless.

"Serverless" is a garbage marketing term in general. It sounds sexy to nontechnical management folks who are used to hearing a bunch of expensive costs and the word "server" associated with them in some fashion. From that view, anything that gets rid of those pesky "servers" sounds like a win.

Not true. While the term is hyped, it is done so for good reasons. It’s not just that management doesn’t want the pesky servers, it’s that most developers themselves don’t want or care for it. Devs want to use platforms that let them quickly deploy their code that implements business logic, and servers/kubernetes and other abstractions aren’t things many devs give a fuck about.

Re: SQLite Is Serverless

#170

Earlier quoted context omitted.

You could make it persist if you have it uploaded somewhere. But then I guess thats not serverless.

"Serverless" is a garbage marketing term in general. It sounds sexy to nontechnical management folks who are used to hearing a bunch of expensive costs and the word "server" associated with them in some fashion. From that view, anything that gets rid of those pesky "servers" sounds like a win.

This perspective has always confused me. Would you say that structured programming was a garbage marketing term, since even though the programming language didn't have goto the compiled machine code has jumps and branches? I would hope not, because the point is that an interface is provided on top of the underlying structure so that you don't have to think about gotos outside of exceptional cases.

Not having to think about what servers in which datacenter are serving a request is pretty convenient. We can argue about whether the pricing for most serverless computing is bad, but as far as the term and the technology itself I don't see how this is different from any other abstraction.

Post reply on HN