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…
SQLite Is Serverless
221–230 of 453 posts
Re: SQLite Is Serverless
#222Earlier 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.
Re: SQLite Is Serverless
#223What 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.
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
#224Earlier 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).
Re: SQLite Is Serverless
#225Earlier 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).
Re: SQLite Is Serverless
#226Does 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 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
#227I 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…
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
#228Earlier 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.
"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
#229My 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…
Re: SQLite Is Serverless
#230Earlier 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…
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.