Turns out you don't need to cram SQLite into a Cloudflare worker anymore. https://blog.cloudflare.com/introducing-d1/
A year later, still in Alpha! But generally available albeit with 100mb limit.
Why SQLite is so great for the edge
11–20 of 148 posts
Re: Why SQLite is so great for the edge
#12I want to hear "What's not great using SQLite compare to PostgreSQL" instead .
No kitchen sink?
Re: Why SQLite is so great for the edge
#13Turns out you don't need to cram SQLite into a Cloudflare worker anymore. https://blog.cloudflare.com/introducing-d1/
A year later, still in Alpha! But generally available albeit with 100mb limit.
There was a recent update about that: https://blog.cloudflare.com/d1-turning-it-up-to-11/
Re: Why SQLite is so great for the edge
#14I want to hear "What's not great using SQLite compare to PostgreSQL" instead .
Poverty in terms of datatypes available to use.
Offhand, Date types are really strings in SQLite.
Personally I'm not yet convinced that the normal SQL representation for what a 'date' object is matches real world use cases that well, or at least doesn't cover all of them.
As a programmer, what I find I want is a 'moment' which retains the input specification. Possibly in a sanitized binary format that's not the literal text, but also isn't a single numeric value either. E.G. Timezone Specifier / City (not just one per TZ!) + Human timespec (5 PM Tuesday the Whatever day of Month in Year) AND a pair of evaluation rules version and 'effective UTC||TAI time' for comparisons. The evaluation version thing needn't be a full version it might even just be a couple bits at the top or bottom of a long range 64 or 128 etc time number of some units. Something that can be used to determine if a value still needs to be updated with the latest rules set rather than using the cached representation.
Re: Why SQLite is so great for the edge
#15In what scenarios would one opt for SQLite over MongoDB or vice versa for a basic CRUD app?
One in which one wishes to retain one’s sanity. It’s _that_ bad, and I don’t especially care for SQLite.
Re: Why SQLite is so great for the edge
#16I want to hear "What's not great using SQLite compare to PostgreSQL" instead .
SQLite is not a good choice if you want to access a DB over the network from different hosts or even from many processes on the same host (later may work good in some cases but not all). Large write (insert/update) volume is also not the best load for SQLite. And of course where replication is needed I would prefer PostgreSQL or MySQL with mature replication support to things like SQLite+litestream.
Re: Why SQLite is so great for the edge
#17In what scenarios would one opt for SQLite over MongoDB or vice versa for a basic CRUD app?
All of them. Plus, MongoDB is not an RDBMS.
Re: Why SQLite is so great for the edge
#18What are the economics with SQLite on edge? Do I have to pay for a copy of the database in every edge location?
Re: Why SQLite is so great for the edge
#19I extensively used SQLite in a telemetry system for an electric race car. The car has an onboard computer, first a Raspberry Pi then a dual core Arm processor. Onboard code logs ~4000 messages a second into three SQLite databases. After a drive session a script merges the three databases into a single SQLite session log. The session log is decoded on a different computer to ~400 columns of time series data again stored in SQLite. This data is then finally converted into a proprietary format for visual analysis.
Prior to SQLite I tried CSV files and raw binary formats. None of them could match the flexibility, ease of use, and throughput of SQLite. My setup has been in use for several weeks now and has processed numerous rows of data. As the SQLite project outlines on its website:
> SQLite does not compete with client/server databases. SQLite competes with fopen().
Re: Why SQLite is so great for the edge
#20I extensively used SQLite in a telemetry system for an electric race car. The car has an onboard computer, first a Raspberry Pi then a dual core Arm processor. Onboard code logs ~4000 messages a second into three SQLite databases. After a drive session a script merges the three databases into a single SQLite session log. The session log is decoded on a different computer to ~400 columns of time series data again stor…
Sounds cool! Any project details anywhere?