Our great sponsors
-
vatcomply
VATcomply is a free API service for vat number validation, user ip geolocation and foreign exchange rates.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
ExtPay
The JavaScript library for ExtensionPay.com — payments for your browser extensions, no server needed.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Bedrock
Rock solid distributed database specializing in active/active automatic failover and WAN replication (by Expensify)
-
-
-
CouchDB
Seamless multi-master syncing database with an intuitive HTTP/JSON API, designed for reliability
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Here's an all-time great post about why you might consider SQLite in production with data about performance: https://blog.wesleyac.com/posts/consider-sqlite
I use SQLite in production for my SaaS[1]. It's really great — saves me money, required basically no setup/configuration/management, and has had no scaling issues whatsoever with a few million hits a month. SQLite is really blazing fast for typical SaaS workloads. And will be easy to scale by vertically scaling the vm it's hosted on.
Litestream was the final piece of the missing puzzle that helped me use it in production — continuous backups for SQLite like other database servers have: https://litestream.io/ With Litestream, I pay literally $0 to back up customer data and have confidence nothing will be lost. And it took like 5 minutes to set up.
I'm so on-board the SQLite train you guys.
[1] https://extensionpay.com — Lets developers take payments in their browser extensions.
VATcomply.com has been using SQLite as a primary database for 2 years and is serving ~70 requests per second without a fault.
HTTPS: https://vatcomply.com/
- https://github.com/rqlite/rqlite
- https://dqlite.io
Simon Willison has written about using SQLite for a "Baked in data" architecture which could be a super interesting method for some situations: https://simonwillison.net/2021/Jul/28/baked-data/
As he notes https://www.mozilla.org/ uses this pattern:
> They started using SQLite back in 2018 in a system they call Bedrock ... Their site content lives in a ~22MB SQLite database file, which is built and uploaded to S3 and then downloaded on a regular basis to each of their application servers.
When I maintained uptime.openacs.org (https://gitlab.com/siddfinch/uptime) and MyTurl (both running AOLserver) I wrote internal versions for a place I was working at.
I switched from Postgres to SQLite for a couple of versions, put mainly because Postgres wasn't "supported" I called SQLite an "internal database thing".
Worked flawlessly for about 7-8 years before both services were gobbled up into micro API services.
At the last count, we have about 14,000 services checked by uptime (about 1,000 every 5 minutes, 2,000 every 10 minutes, the rest every 15). Probably had about 60,000 tinyurls in MyTurl. We also ran the MyTurl urls through uptime every night to look for bad links. The system go hammered, often.
It took minor tweaking to get the the best performance out of the database and AOLserver has some nice caching features, which helped to take the load off the database a bit. But overall, it worked as well as the Postgres counterpart.
And now, I have to figure out why I never released the SQLite version of both.
Here's an all-time great post about why you might consider SQLite in production with data about performance: https://blog.wesleyac.com/posts/consider-sqlite
I use SQLite in production for my SaaS[1]. It's really great — saves me money, required basically no setup/configuration/management, and has had no scaling issues whatsoever with a few million hits a month. SQLite is really blazing fast for typical SaaS workloads. And will be easy to scale by vertically scaling the vm it's hosted on.
Litestream was the final piece of the missing puzzle that helped me use it in production — continuous backups for SQLite like other database servers have: https://litestream.io/ With Litestream, I pay literally $0 to back up customer data and have confidence nothing will be lost. And it took like 5 minutes to set up.
I'm so on-board the SQLite train you guys.
[1] https://extensionpay.com — Lets developers take payments in their browser extensions.
This isn't a typical use case. FWIW, a decade ago, we used sqlite as the persistence mechanism for an in-memory KV store called membase. (See https://github.com/membase/ep-engine). This was powering 50M+ DAU traffic in production for very intense write-heavy traffic. It did its job well. Around that time we also considered leveldb (and rocksdb a bit later) as alternative to sqlite.
Many of the replies here attest to the simplicity and fast performance of SQLite particularly for serving pages or data. But how well does SQLite fare in concurrent write/insert situations?
Although SQLite is not designed for this type of scenario, this discussion higlights there's a strong demand for a concurrent client/server RDMS that is simple, performant and easy to deploy? PostgreSQL is not simple or easy to delploy. Hence the appeal of SQlite.
For example, could SQLite power a discussion forum of moderate (or more) activity? The Nim language forum is powered by SQLite, but activity in the forum is fairly low [1]
Between the simplicity of SQLite and the complex, heavyweight that is PostgreSQL, there is a chasm between these database opposites. (Another poster mentions the concurrent Firebird RDMS [2] as an less heavyweight alternative to PostgreSQL.)
[1] https://forum.nim-lang.org/
[2] https://firebirdsql.org/en/features/
I used it for a Magic: the Gathering Commander tool I made recently[0]. It was pretty useful, since the point of the tool was on-device card searching and deck organization. I was even able to sync the data between multiple computers just by putting it in a NextCloud folder.
Aside from some surprises regarding packaging it together with the rust crate and inability to rename columns, I'm really happy with it. Easier than deploying postgresql, more useful than documents.
[0] https://github.com/Endominus/Lieutenant
2. Check the WAL if any previously transaction modified one of those b-trees. If so, this means we have to rerun our transaction.
I've seen it done in software transactional memory (STM) systems as well. It's really beautifully simple, but I think there are a lot of devils in the details.
[1] https://github.com/sqlite/sqlite/blob/9077e4652fd0691f45463e...
I am using sqlite where a simple persistence layer is needed, both as the sole in the project or along with a full-fledged database. There are many such projects, once you realize that a database is just an abstraction; for example, for caching in a larger project, or to store results for a subsection of the project. But of course also for smaller, standalone projects.
Also, take a look at ws4sqlite (https://germ.gitbook.io/ws4sqlite/) for a middle ground between SQLite (embedded) and rqlite/dqlite: it's "normal" sqlite addressable via web services. May be useful in some scenarios.