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

161–167 of 167 posts

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

#161

Post by mnming »

Neither Litestream and LiteFS meet my SQL needs: Litestream is a single writer system, LiteFS has data consistency risk. I can't justify replacing Postgresql for them.

I do understand those tools expanded the use cases of sqlite a lot and they are pretty cool in how they pulled it off. But I'm surprised Fly's investing here; feels like it tarnishes their infra provider rep.

If they do want to continue this investment, maybe investing in things like rqlite will be more appropriate for an infra shop.

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

#162

Post by sodapopcan »

pmarreck wrote: post #151
sodapopcan wrote: post #90

Earlier quoted context omitted.

This is very close to my experience as well. Unfortunately, it was in reverse for me :( We had a custom solution and people were happy. A new tech lead came in and didn't like that the custom solution was PHP that still had some legacy spaghetti in it, so we switched to an off the shelf solution. It was very painful. People were unhappy.

> that still had some legacy spaghetti in it I'm going to take a wild ass guess here that you are wildly understating the "bit of legacy spaghetti"

Your wild guess is flat out wrong. When the previous tech lead came in the entire thing was spaghetti. His strategy was to slowly start bringing in some order to the chaos which we did, diligently, over two years making tons of progress. It was a homebrewed framework but it was really nice (he'd had years of experience contributing to Drupal). All the business critical functionality had been converted to this. The spaghetti parts were features that were essentially "complete". Since they never needed updating, they worked fine as they were.

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

#163

Post by unshavedyak »

geysersam wrote: post #154
endisneigh wrote: post #52

Earlier quoted context omitted.

Any self respecting e-commerce site would want fault tolerance and strong consistency even with potential network partitions, so definitely not SQLite as described in article

Why would they need strong consistency? What's shown on the page the user sees is never strongly consistent with the db anyway.

I have this same discussion at work frequently. Everything thinks they need instantly up to date, yet our customers work for 10 minutes on a stale document and no one cares.

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

#164

Post by marcosdumay »

dangets wrote: post #136
marcosdumay wrote: post #121

Earlier quoted context omitted.

> 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?

Yes, I meant that plpgsql is on a complete different level from t-sql (and t-sql is already on a different level from pl/sql).

But also, you don't need extensions to enable other languages, postgres allows those out of the box (through the C-ABI). Anyway, that is not very compelling, because plpgsql is quite good already.

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

#165

Post by pmarreck »

sodapopcan wrote: post #162
pmarreck wrote: post #151

Earlier quoted context omitted.

> that still had some legacy spaghetti in it I'm going to take a wild ass guess here that you are wildly understating the "bit of legacy spaghetti"

Your wild guess is flat out wrong. When the previous tech lead came in the entire thing was spaghetti. His strategy was to slowly start bringing in some order to the chaos which we did, diligently, over two years making tons of progress. It was a homebrewed framework but it was really nice (he'd had years of experience contributing to Drupal). All the business critical functionality had been converted to this. The sp…

Drupal is the one piece of technology that I did 1 project in and would never work with again no matter what the pay was.

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

#166

Post by JohnBooty »

pmarreck wrote: post #152
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 completely avoided the need for maintaining an additional dependency (ElasticSearch) simply by taking advantage of fulltext search in Postgres. This did involve some writing of triggers and stored procedure code (which was generated by server-side code, but anyway), which is technically application logic. There are no perfect solutions in engineering, only tradeoffs.

I love this! There are definitely cons to moving functionality to Postgres, but avoiding an additional dependency can be a massive pro.

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

#167

Post by sodapopcan »

pmarreck wrote: post #165
sodapopcan wrote: post #162

Earlier quoted context omitted.

Your wild guess is flat out wrong. When the previous tech lead came in the entire thing was spaghetti. His strategy was to slowly start bringing in some order to the chaos which we did, diligently, over two years making tons of progress. It was a homebrewed framework but it was really nice (he'd had years of experience contributing to Drupal). All the business critical functionality had been converted to this. The sp…

Drupal is the one piece of technology that I did 1 project in and would never work with again no matter what the pay was.

I wouldn’t know I’ve never used it.
Post reply on HN