4 ms·
I’m bullish on SQLite, and this is mostly a great article, but this kind of stuff is flat-out misleading: > When you put your data right next to your applicati
by jmull 3y ago
I’m bullish on SQLite, and this is mostly a great article, but this kind of stuff is flat-out misleading:
> When you put your data right next to your application, you can see per-query latency drop to 10-20 microseconds.
As if postgres and others don’t have a way to run application logic at the database. I like the SQLite way of doing it — you pretty much freely choose your own host language — anything with a decent SQLite client will work. While in postgres, for example, you’ll probably end up with pgplsql (there are others, but there are constraints). So this isn’t about latency, as the whole section of the article suggests.
There’s actually a relative weakness in SQLite here, since it doesn’t include a built-in protocol to support running application logic separate from the database. That’s also architecturally useful, and so you may have to find/build a solution for this.
Just adding replicas isn’t a general solution either, because each replica has an inherent cost: changes have to somehow get to every replica.
E.g., systems can grow to have a lot of database clients. In traditional setups you begin to struggle with the number of connections. You might think with SQLite, “hey, no connections, to problems!” but now, instead of 1000 connections you’ve got 1000 replicas. That’s something you’re going to have to deal with… that’s 1000x write load, 1000x write bandwidth.
Perhaps fly.io has a solution for this, but I suspect it’s going to cost you.
- TylerE 3y agoThat whole series of blog posts is an ad for fly.io.
- sodapopcan 3y ago> As if postgres and others don’t have a way to run application logic at the database. I think it's reasonably fair of them not to specify this. The target audience of this article is people who are writing their applications in languages like Elixir, JS, Ruby, Python, and are not going to be interested in pushing all of their business logic to the db.
- JohnBooty 3y agoAs if postgres and others don’t have a way to run application logic at the database. I mean... This is probably the least popular possible thing you can possibly suggest as an engineer in 2023. Me? I actually think pushing app logic to the DB is a solid, underrated, and possibly even optimal solution for a lot of scenarios. But don't tell anybody I said that. I might get beaten up. That's probably why fly.io sort of glosses over it as a possibility. Almost nobody is even considering it as an option in 2023.
- Micoloth 3y agoHonest question.. Why? I’m always thinking that a db that can also run business logic would be the ultimate backend solution for crud apps. I know there are several options to do it, but I always assumed Postgres did not support it. What do people have against it?
- candiddevmike 3y agoFew reasons: - Enforce application logic with constraints so you don't have to duplicate it - Use triggers and get access to things like old and new without having to create a bunch of transactions - If you have multiple apps sharing a DB, you either keep your business logic consistent across them vs just doing it in the database - You can version your business logic with your schema
- __jem 3y agoFriction with modern devops practices is a big one.
- xboxnolifes 3y agoThe tooling around maintaining logic-in-db is worse than the tooling for logic-out-of-db.
- simonw 3y agoI think the main thing is that most people still aren't working with a good migrations system to manage changes to their schema... which means logic held in database triggers and stored procedures quickly becomes a non-version-controlled not-properly-tested mess. Good migration systems exist, and people should use them! I held off on doing interesting things with triggers for more than a decade. In the past year I've started leaning into them much more heavily (actually using them in SQLite) because I have confidence that I can both write good tests for them and have good migrations automation in place for version-controlling my schema.
- deleted 3y ago[deleted]