Live data from Hacker News

SQLite Is Serverless

sqlite.org

221–230 of 453 posts

Re: SQLite Is Serverless

#221
post #164

Earlier quoted context omitted.

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

> Have you tried to figure out where to install the server or asked what the system requirements were for it? Not exactly, but asking "where to install the server & client and what are the system requirements for each" is not that different to asking "where to install the client and what are the system requirements for it", even when there is no server. > Have you grown concerned that once the system moves into produ…

bane said "not stupid"

Re: SQLite Is Serverless

#222
post #159

Earlier quoted context omitted.

This is overly reductive. “Serverless” might be overhyped, but amongst devs and ops it is a perfectly good way to succinctly describe a very specific architecture with real merit. Paying for exactly the compute time i use is pretty sexy to me when I want to deploy and scale a side project.

What was wrong with "managed"? It's pretty generic and transfers across many domains and also, more fairly descriptive of what's going on.

"managed" is an AWS instance or a digital ocean droplet. "serverless" is an entirely different thing.

Re: SQLite Is Serverless

#223
post #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.

I am working on RediSQL[1] and I am about to launch a managed version.

The interface will be either HTTP or Redis protocol, you create your database, and daily I will back it up on S3.

(If interested you can subscribe for updated here: https://simplesql.carrd.co/

[1]: https://redisql.com/

Re: SQLite Is Serverless

#224
post #217
post #200

Earlier quoted context omitted.

No, SQLite provides no RDBMS functionality. It is not an RDBMS. It is a file format. Saying that a program that opens and reads/writes a file through a file format API is a light RDBMS turns almost every program in history into an RDBMS. If SQLite didn't force you to use SQL as the read/write logic, absolutely nobody would confuse it for an RDBMS. That's because it's a file format.

It can open multiple files (the transaction log).

Almost any modern programming language can open multiple files.

Re: SQLite Is Serverless

#225
post #214
post #202

Earlier quoted context omitted.

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?

SQLite is a whole library with complicated locking protocol options etc. and works with multiple files of different formats (e.g. separate transaction log).

Since the file format specification is available, you can write your own code that directly reads/writes to SQLite files. You can't even have to use the logs and journaling options. You don't even have to use SQL.

Re: SQLite Is Serverless

#226

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…

I will shamelessly plug myself again.

I am the main author of RediSQL [1] and I am about to launch a managed service for it.

It will allow to write SQL (SQLite dialect) against an HTTP or Redis protocol, to make thing clearer: https://simplesql.carrd.co/

Eventually it will upload your database to an S3 bucket for backup.

[1]: https://redisql.com/

Re: SQLite Is Serverless

#227
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…

Sqlite implements all of the features you would expect from a relational database, including indexes, transactions, write ahead logging, consistency, and provides a SQL wrapper on top of its file API. _This is what makes it a database and not just a file format_. To the client, whether or not the API is happening over a socket or a locally linked library is irrelevant. How connection pooling works is also not relevant to whether it is a database or just a file format.

Calling Sqlite just a file format is kind of like calling Python "just a syntax specification." That's part of it, but we're talking about the actual implementation of it (probably CPython).

Re: SQLite Is Serverless

#228
post #222

Earlier quoted context omitted.

What was wrong with "managed"? It's pretty generic and transfers across many domains and also, more fairly descriptive of what's going on.

"managed" is an AWS instance or a digital ocean droplet. "serverless" is an entirely different thing.

"Serverless" is another level of abstraction and management, that's it. Are you proposing that a term collision adds too much confusion?

"Managed" hosting has been around for decades as have "managed" services, in general, long before Amazon even existed. EC2 brought a new level/layer of automation and management ontop of what colo datacenters used to do, provide scaling etc. To be clear I'm not saying it's simple but "managed" describes much of it.

Re: SQLite Is Serverless

#229
post #49

My understanding of serverless = easily scalable, managed service. But somehow the word annoys people. Maybe we should find a better word?

For me, serverless is not just "easy" scaling or a managed service, but completely automatic and elastic scaling with metered billing. If you can go from 1 to millions of requests without touching your infrastructure or dropping requests, then that's serverless. If you have to provision larger instances or even wait 10 minutes for your autoscaling policy to spin up new VMs so you can serve those requests, then it's n…

I agree, yours is definitely a better description.

Re: SQLite Is Serverless

#230
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…

File formats don't have an API. > SQLite is a file format with a familiar API and uses SQL as the logic for searching/adding data to the file. That description is for a library, not a file format. SQLite is a library, that saves to a convenient format and allows you to query the file using the SQL syntax. File formats dont have "logic". You are arguing the equivalent that Word is a file format. While there is a Word…

> File formats don't have an API.

So when you read/write to any other file format, you just read/write bytes directly to/from disk and re-implement the parsing and read/write logic in your own code every time?

> File formats don't have "logic".

Every file format has logic otherwise it's just random entropy in an arbitrarily long byte stream on a disk. How to read/parse and interact with that format depends entirely on the logic and scheme for that file. For example, many file formats have an index of some kind that you must read and parse before you can figure out where the other data lives, compressed file formats often store a dictionary, image formats often have a compression/decompression logic that must be followed for reading/writing to them.

> You are arguing the equivalent that Word is a file format. While there is a Word file format, Word itself is an application.

.docx is the file format for Word documents. There are many APIs and programs that can read/write to/from .docx files.

Post reply on HN