131–140 of 274 posts
I used it for ETL process extensive which is great. I still don't know how people use it for concurrent writes like a simple ToDo webapp?
I don't doubt the power of SQLite, but its difficult to see why its worth using over Postgres anyways. This is what it takes to run a basic postgres database on my own PC (in a docker compose file): postgres: image: postgres:12.7 container_name: postgres environment: - PGDATA=/var/lib/postgresql/data/pgdata - POSTGRES_PASSWORD= volumes: - ./volumes/postgres/:/var/lib/postgresql/data/ For someone who's completely alle…
I'm not really sure why this post has downvotes. docker-compose dramatically lowers the barrier for setting up a single machine with multiple services (your service, db, etc). For a similar experience you do the same with AWS RDS or equivalent. Performance will be better and worse in various situations but if your software still fits in one machine you're largely going to be "ok." Backups, restore, monitoring, etc ar…
We've been using SQLite in production as our exclusive means for getting bytes to/from disk for going on 6 years now. To this day, not one production incident can be attributed to our choice of database or how we use it. We aren't using SQLite exactly as intended either. We have databases in the 100-1000 gigabyte range that are concurrently utilized by potentially hundreds or thousands of simultaneous users. Performa…
Earlier quoted context omitted.
> How is this setup fault tolerant? It is not. > What happens if there is a hardware failure? The product would suffer a total outage until manual intervention takes place. A restore of the VM from snapshot would be carried out by the customer. Some loss of the most recent business data would occur (i.e. between latest snapshot and time of failure). All of this is understood and agreed to by our customers. > How do y…
Interesting. For an extremely specific use case and with users who understand and accept the caveats of this approach I'm sure it would work well enough. The most confusing thing to me is that there is apparently an intersection of users who are ok with an outage and data loss with users who want a product which can > execute queries and reliably receive results within microseconds What is your product? Who are these…
We've been using SQLite in production as our exclusive means for getting bytes to/from disk for going on 6 years now. To this day, not one production incident can be attributed to our choice of database or how we use it. We aren't using SQLite exactly as intended either. We have databases in the 100-1000 gigabyte range that are concurrently utilized by potentially hundreds or thousands of simultaneous users. Performa…
> It is my understanding that something about not having to take a network hop and being able to directly invoke the database methods makes a huge difference. Are you able to execute queries and reliably receive results within microseconds with your current database setup? with SQL Server you can get a very fast local connection by specify "server=(local)" in the connection string - this uses shared memory protocol b…
If I am constraining my SQL Server usage to fit on 1 box, I might as well use SQLite (assuming no future plans for horizontal scaling).
Earlier quoted context omitted.
> There is no easy way to save the data directly to the file system. That's what absurd SQL is for (link in the parent comment).
I read that one and agree it feels absurd. Not something I want to depend on.
The repo's readme is a bit misleading and it does make it look like a mad scientist experiment but you can read more about it here (really interesting stuff): https://jlongster.com/future-sql-web
Obviously this project is still young, but I find it convincing (disclaimer: I don't use it yet).
There must be some scaling limits to encounter using this combination, but wouldn't you love to have that problem?
Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to e…
SQLite hides a ton of complexity that lives in the filesystem. It’s incredibly hard to do robust IO correctly with the APIs we have. I almost always choose SQLite for persisting to disk over JSON files. It essentially removes a large class of bugs and is robust enough that I’m not worried about introducing new problems.
Since they are using Go, couldn't you say the same thing about the Golang std library? As long as they know how to use a local file as database (do the swap, flush, etc...) I don't see the problem.
We've been using SQLite in production as our exclusive means for getting bytes to/from disk for going on 6 years now. To this day, not one production incident can be attributed to our choice of database or how we use it. We aren't using SQLite exactly as intended either. We have databases in the 100-1000 gigabyte range that are concurrently utilized by potentially hundreds or thousands of simultaneous users. Performa…
> It is my understanding that something about not having to take a network hop and being able to directly invoke the database methods makes a huge difference. Are you able to execute queries and reliably receive results within microseconds with your current database setup? with SQL Server you can get a very fast local connection by specify "server=(local)" in the connection string - this uses shared memory protocol b…
For remote databases, setting the TWO_TASK environment variable to the server's TNS descriptor is one way to force a network login.