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

SQLite Is Serverless

sqlite.org

Post reply on HN
Print view View original

201–210 of 453 posts

Re: SQLite Is Serverless

#201

Post by bane »

travbrack wrote: post #193
bane wrote: 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've seen several software projects that are built for rdbms let you use sqlite. It works.

They're using SQLite as the file format for persisting data. It's a great file format for this. You can even build an RDBMS over top of uncompressed WAV files if you want. It doesn't make WAV files RDBMs.

Re: SQLite Is Serverless

#202

Post by bane »

catalogia wrote: post #195
bane wrote: post #188

Earlier quoted context omitted.

SQLite is a file format with a familiar API and uses SQL as the logic for searching/adding data to the file. Approach it exactly the same way you'd approach using a CSV file and all the confusion and overthinking about it goes away. Approach it as a stripped down RDBMS and you end up with all kinds of questions about support for this or that RDBMS familiar service. You can write your own SQLite file reader/writer. He…

> No! SQLite is not an embedded RDBMS. It's a file format. You keep saying it's a file format, but it's quite possible to use sqlite without persisting anything to a file at all. rc = sqlite3_open(":memory:", &db);

You can read/write CSV files, JSON, JPEG, WAV, MP3, MP4, etc. into memory as well. That doesn't make any of them an RDBMS.

SQLite is a file format. It has a nice API and uses SQL as the domain language for read/write logic. If it didn't use SQL for the logic, would you still be confused?

Re: SQLite Is Serverless

#203

Post by hartator »

bane wrote: 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…

MySQl, Postgres, or MongoDB still store your date in files. So there are also “just a file format”. You do have one extra step - the db server process - to access the files.

Re: SQLite Is Serverless

#204

Post by vdfs »

bob1029 wrote: post #119
dana321 wrote: post #91

It does allow multiple applications to access the same database at the same time, but when you do so it really hurts performance. I noticed this when i wrote a web crawler in go and used sqlite as the backend. As soon as i connect using the command line interface, it slows down significantly. Just something to bear in mind if you want to use it with multiple processes!

Multiple processes is an instant anti-pattern for a single SQLite database. I would stop and reconsider your approach before trying to build this solution using it. The way I see it there are 3 options: 1) Implement another process which will have exclusive ownership of the shared SQLite database, and then use some IPC scheme to delegate database operations from multiple processes. 2) Give each process its own copy o…

It's ironic how using a severless database require your app to be the server and do top-level access management to the database

Re: SQLite Is Serverless

#205

Post by catalogia »

bane wrote: post #202
catalogia wrote: post #195

Earlier quoted context omitted.

> No! SQLite is not an embedded RDBMS. It's a file format. You keep saying it's a file format, but it's quite possible to use sqlite without persisting anything to a file at all. rc = sqlite3_open(":memory:", &db);

You can read/write CSV files, JSON, JPEG, WAV, MP3, MP4, etc. into memory as well. That doesn't make any of them an RDBMS. SQLite is a file format. It has a nice API and uses SQL as the domain language for read/write logic. If it didn't use SQL for the logic, would you still be confused?

Being a file format is only one aspect of what SQLite is. SQLite describes itself as "SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine." I think that is a better, more encompassing, description than "it's a file format"

Edit:

If SQLite lacked any ability to persist data to disk, it would still be very useful as an in-process SQL engine for many sorts of problems. Certainly not as useful as it currently is, but nevertheless still useful.

I'd say the file format without the SQL engine, or the SQL engine without the file format, would be like peanut-butter without jelly. Certainly not pointless, but the real magic comes from the combination of the two.

Re: SQLite Is Serverless

#206

Post by Frost1x »

wyago wrote: post #170
Frost1x wrote: post #151

Earlier quoted context omitted.

"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…

The criticism is on the nomenclature, not what's being provided. "Structured programming" is... pretty well named IMHO. Serverless is a misnomer at best and borders on fraud/false advertising from the name alone.

The technologies are fine and there are potentially useful cases for it. It's no silver bullet though and is overhyped IMHO.

Re: SQLite Is Serverless

#207

Post by sgt »

cle wrote: post #196

> It is important to understand these two different definitions for "serverless". When a database claims to be "serverless", be sure to discern whether they mean "classic serverless" or "neo-serverless". It's really not important to understand that distinction, because this author seems to be the only one making it. Everyone knows what "serverless" means at this point, and it's not an embedded DB.

After this article has been uncovered by HN, that may just be about to change.

Re: SQLite Is Serverless

#208

Post by hartator »

bane wrote: post #164
lucideer wrote: post #156

Earlier quoted context omitted.

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 w…

The original document is from SQLite documentation. I think it’s fair for them to make a case why sometimes a file database > a server database. People asking these questions are not stupid. We all have to start somewhere.

Re: SQLite Is Serverless

#209

Post by specialbat »

buckminster wrote: post #99
oldgradstudent wrote: post #23

> Of those that are serverless, SQLite is the only one known to this author that allows multiple applications to access the same database at the same time. IIRC, MS Access allowed that, which explained a lot of its popularity.

This was a standard feature of flat file databases in the early 90s. There were many products. They often had an ODBC driver, which provided a SQL front end. dBase .dbf files were often used for storage. The arcane file locking in Windows is intended for exactly this kind of application. Apart from quality (!), SQLite's main advantage over these products is broad platform support. And continued existence.

We still have a multi user desktop application that uses the Borland database engine and dbf files over a windows file server. The BDE is no longer supported but it still works

Re: SQLite Is Serverless

#210

Post by bane »

hartator wrote: post #203
bane wrote: 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…

MySQl, Postgres, or MongoDB still store your date in files. So there are also “just a file format”. You do have one extra step - the db server process - to access the files.

Yes! You've defined the difference between an RDBMS (the server process and whatever else it does) and the file format the data is stored in.

SQLite is just a file format. If you want it served up over some kind of server, you have to build your own (and most people do), or use a server that somebody else has built for you (there's a couple out there).

Post reply on HN