Live data from Hacker News

SQLite is all you need for durable workflows

obeli.sk

151–160 of 413 posts

Re: SQLite is all you need for durable workflows

#151

Meta comment: This is a domain under my countries TLD (Slovakia) and it is one of the handful of words that are a word with the TLD in my language (and coincidentally) also in English. Every now and then, I will check on the domains with a retrograde dictionary for domains that have this property and root of this particular domain had a roundcube email server on it (can be checked on archive.org). After further check…

That's a crazy story. National TLD is a weird business from the beginning.

Re: SQLite is all you need for durable workflows

#152
post #109
post #9

Earlier quoted context omitted.

Could you give an example of a case where you'd use SQLite instead of jq or grep through Markdown?

> an example of a case where you'd use SQLite instead of jq or grep through Markdown? Usually we end up writing a script to incrementally refresh a data-set I'm analyzing (or have someone send me a copy after they pull it). I've been using sqlite for anything which needs an UPDATE - modifying a row deep inside the data-set with jsonl is a pain. My github is full of java programs which update sqlite3 files with thread…

UDF: User Defined Function

Re: SQLite is all you need for durable workflows

#153
post #85

Earlier quoted context omitted.

Well if you run a tiny single-threaded app then SQLite is a nice simplification over spinning up a separate machine for Postgres.

Or you can run postgres on the same machine as the application, which lets you much more easily migrate if the time comes when you need to scale to multiple application servers. There's a world between "local file" and "network DB server", running a DB server locally has lots of benefits from being able to easily query from outside if needed to forcing you to consider concurrency without the latency overhead of a net…

Now you've added a substantial dependency, and annoying setup requirements. Good luck doing this for a native app on mobile or desktop.

Re: SQLite is all you need for durable workflows

#154
post #22

I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…

I absolutely 100% do not understand it either. At all. Every time I try to over the last year or two I come away with the conclusion its something that sounds cool (to me too!) but is guaranteed to cause more problems than more obvious solutions. That being said I'd kill for someone who used it and benefited to explain it to me in a practical sense. (specifically where syncing is involved, and syncing a subset of the…

It's very likely that you have multiple SQLite databases in your pocket right now. It's one of the most widely deployed pieces of software on the planet. If your conclusion is that it's guaranteed to cause more problems than other solutions, then that's on you.

Re: SQLite is all you need for durable workflows

#155
post #67

Earlier quoted context omitted.

GP calls out concurrency as a weakness of SQLite. Most of the examples here don't experience the same load even a moderately sized web service experience day to day. And no, being a part of the python standard library doesn't means it is being used by the average python user. These days I'd say at least half of them are just there for machine learning.

SQLite is good for read-concurrency, not great for write-concurrency.

SQLite requires writes run sequentially. Most SQLite write operations take single digit milliseconds or even microseconds. If your writes are inexpensive (inserting or updating single small rows) you'll probably never even notice the queue.

Re: SQLite is all you need for durable workflows

#157
post #128

Earlier quoted context omitted.

You can use strict tables: https://sqlite.org/stricttables.html

This could enforce dates are strings. They wanted to enforce dates are dates I thought.

  create table events (
    id integer primary key,
    name text not null,
    event_date text not null check (
      -- YYYY-MM-DD
      event_date glob '[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
      and date(event_date) is not null
      and date(event_date) = event_date
    )
  );
In Python that raises this error if the date is invalid:

  sqlite3.IntegrityError: CHECK constraint failed:
    event_date glob '[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]'

Re: SQLite is all you need for durable workflows

#158
post #113

I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with…

Word on HN is that you're either paying more money than you expected for temporal's managed solution or taking on substantial ops burden ultimately running their very heavy system yourself. I wouldn't know, I've not done either, but I'd like to learn more from your or other's experience.

Very heavy indeed, people will confuse the durability that Temporal provide with all the other properties a distributed system needs. They will then think that Temporal will solve all their problems.

Re: SQLite is all you need for durable workflows

#159

Earlier quoted context omitted.

Are logs all you need for durable workflows? I'm confused here. How'd persist and query nested or related data over logs? By logs I assume you mean something like elasticsearch or meilisearch?

I assume they meant a log like a WAL. A WAL should be (quite literally?) all you need for durable workflows. A distributed WAL (to survive a machine death) would also probably be something I'd want, and … something I'm not sure you're getting directly from SQLite.

Is it common to use logs as a proxy for write-ahead logs?

Re: SQLite is all you need for durable workflows

#160
post #74

Earlier quoted context omitted.

I guess I need to dive deeper into this as I do not understand the implications you gave me, but I appreciate the attempt. Generally I understand why concurrency is good in many cases, I just dont get why its important for database stuff too. Edit: thanks for clarifying in the edit, makes a lot more sense.

Imagine if every tweet had to go through a one-at-a-time queue before being persisted. There's about 6000 tweets per second, so you would have to be able to save them at <0.17ms per tweet or else you would become backlogged. If you are getting backlogged, you have to buffer those incoming tweets somewhere until they can be writted, and eventually that buffer gets full and you start losing tweets.

If we imagine 1 tweet = 1 transaction, that's only 6k tps. 6k tps is completely achievable, dare I say even pedestrian for an optimized database. And most systems are operating far below the scale of Twitter/X.
Post reply on HN