Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm all-in on server-side SQLite (2022)

fly.io

Post reply on HN
Print view View original

131–140 of 167 posts

Re: I'm all-in on server-side SQLite (2022)

#131

Post by nitwit005 »

sodapopcan wrote: post #28
erulabs wrote: post #17

I hope fly is able to make it. I’m rooting for them - however - I’m starting to wonder if the SQLite push isn’t more “this is fun and interesting to build” and less “customers want this”. Don’t get me wrong - this is neat - but I’d never suggest anyone to actually use this outside of a fun experiment. The problem with existing SQL dbs isn’t really the architecture - its the awful queries that do in memory sorting or…

Lots of smaller businesses could do fine with this if they don't have a write-heavy workload. Like an ecomm shop, for instance.

If you're a smaller e-commerce business, your whole site can probably be cached aside from auth, checkout, and order history.

Re: I'm all-in on server-side SQLite (2022)

#132

Post by eek2121 »

erulabs wrote: post #17

I hope fly is able to make it. I’m rooting for them - however - I’m starting to wonder if the SQLite push isn’t more “this is fun and interesting to build” and less “customers want this”. Don’t get me wrong - this is neat - but I’d never suggest anyone to actually use this outside of a fun experiment. The problem with existing SQL dbs isn’t really the architecture - its the awful queries that do in memory sorting or…

The first iteration of my website used sqlite. I only switched away because the growing audience made me nervous.

Re: I'm all-in on server-side SQLite (2022)

#134

Post by JohnBooty »

sodapopcan wrote: post #125
JohnBooty wrote: post #83

Earlier quoted context omitted.

As 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…

I run a bunch of business logic in the database but have no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps?

How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)?

    no interest in writing my whole application as triggers 
    or whathaveyou. It's a bit of a middle ground, perhaps?
Yeah, I think our position is often misunderstood as "put everything in the database layer."

That is definitely not how I think. I just think moving stuff to the database layer is one possible tool in the toolshed.

One thing I like to use it for is when it's a "low level" database concern, like generating an audit trail whenever a particular table is changed. To me, populating that audit trail is clearly a database concern and not an application concern. (And if there are heavy writes to that table, the performance difference may be large)

Re: I'm all-in on server-side SQLite (2022)

#136

Post by dangets »

marcosdumay wrote: post #121
vsareto wrote: post #107

Earlier quoted context omitted.

>Me? I actually think pushing app logic to the DB is a solid, underrated, and possibly even optimal solution for a lot of scenarios. The languages for writing it are not as comfy as traditional programming languages, which affects how expressive and maintainable your code will be. The tools for debugging a regular language might also be better than debugging application logic in SQL. Having done some of this in T-SQL…

> Having done some of this in T-SQL Don't expect your experience with any other DBMS to give you an idea about how nice it is to program in Postgres. It's still not as nice as creating some independent code. But Postgres is quite nice to program in.

Genuinely curious what your experiences of postgres programming you are fond of. Are you talking about functions & procedures in pgsql or are you using an extension to enable a different language?

Do you have any interesting blog links?

Re: I'm all-in on server-side SQLite (2022)

#137

Post by jmull »

JohnBooty wrote: post #134
sodapopcan wrote: post #125

Earlier quoted context omitted.

I run a bunch of business logic in the database but have no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps?

How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps? Yeah, I think our position is often misunderstood as "put everything in the database layer." That is definitely not how I think. I just think moving stuff to the database layer is one possib…

> How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)?

Not the previous poster but...

I would think of it as an application layer that is running at the database.

It would make the most sense for logic that is closely coupled to data access... exactly what that is depends on your app. Low-level access control policies... maybe you need to dig data out of a bunch of tables and turn it in to a hierarchy based on complicated user prefs also stored in the database... Or the opposite where you have complex data coming in that needs to be written to a bunch of tables, especially when there's back and forth.

I don't think very many should try to put their whole app in there. Database compute tends to get expensive and complicated to scale, so stuffing things in there just because you can might run in to trouble. Not to mention (except for SQLite) the runtime environment is seriously constrained in all kinds of ways.

The previous post mentions triggers but I don't know what those have to do with this. The chance that triggers are right solution to any given problem is approximately 0% in my experience.

Re: I'm all-in on server-side SQLite (2022)

#138

Post by sodapopcan »

JohnBooty wrote: post #134
sodapopcan wrote: post #125

Earlier quoted context omitted.

I run a bunch of business logic in the database but have no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps?

How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps? Yeah, I think our position is often misunderstood as "put everything in the database layer." That is definitely not how I think. I just think moving stuff to the database layer is one possib…

All aggregating and all math I do in the db. Stuff like taxes, royalties, any reporting stuff (that should probably be in a column store). It may seem like a no-brainer to do that but you'd be surprised. I worked at a fintech briefly and ALL the math was done in Elixir which surprised me. I also usually like to do permissions in SQL, ie, selecting a record based on a permission as opposed to grabbing the record then checking (I go back and forth on this). I do like to have everything that is going on represented in the application code, though, so I've never actually written a trigger in my life... I did write a stored procedure once for generating unique product codes... I never said I was a particularly good engineer, lol. But ya, even in the case of a cascading delete or something I still like to spell that out in application code so there are no surprises. Of course, I've never gotten to work on a team where everyone felt this way.

Audit trails seems like an interesting case I have thought about before (I have been a part of building audit trails at the app level before). It's something I've been curious about but never looked into. I think it depends on how detailed they have to be. Like, just creating a history of every table seems a little wasteful to me, but you're probably talking more nuanced than that. I did talk to someone who worked somewhere where that was the strategy.

Re: I'm all-in on server-side SQLite (2022)

#139

Post by sodapopcan »

jmull wrote: post #137
JohnBooty wrote: post #134

Earlier quoted context omitted.

How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? no interest in writing my whole application as triggers or whathaveyou. It's a bit of a middle ground, perhaps? Yeah, I think our position is often misunderstood as "put everything in the database layer." That is definitely not how I think. I just think moving stuff to the database layer is one possib…

> How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? Not the previous poster but... I would think of it as an application layer that is running at the database. It would make the most sense for logic that is closely coupled to data access... exactly what that is depends on your app. Low-level access control policies... maybe you need to dig data out o…

I think this is essentially what I meant? In any event, I responded a little clearer but ya, shaping data and moving it around is a big thing I feel should be done in the DB. Having spent time in the rails world for several years, I worked with a lot of people who didn't want to do ANYTHING at the DB level. Like, obviously they'd do joins and things ActiveRecord could do easily, but they'd be fine pulling in a bunch of rows and reducing them in Ruby. That drove me nuts. I'm not an optimization junky at all but I do not like that in the slightest. Not only is it wasteful and slower, in my experience it's also more error prone.

Re: I'm all-in on server-side SQLite (2022)

#140

Post by sodapopcan »

nitwit005 wrote: post #131
sodapopcan wrote: post #28

Earlier quoted context omitted.

Lots of smaller businesses could do fine with this if they don't have a write-heavy workload. Like an ecomm shop, for instance.

If you're a smaller e-commerce business, your whole site can probably be cached aside from auth, checkout, and order history.

I can say with authority that this is true! We used to store our whole massive catalog in Varnish.
Post reply on HN