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

51–60 of 167 posts

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

#51

Post by bambax »

andrewstuart wrote: post #23

I can’t see any valid reason not to use Postgres at the back end, unless you are in some sort of environment such as embedded or cloudflare workers that requires it. Or if you need a graph database there are better choices than Postgres. Postgres is good on multi core, incredibly feature rich, multi user, supported by everything, lightweight and has all the tools for production workload and management. All stuff that…

> I can’t see any valid reason not to use Postgres at the back end

From TFA:

> if you don’t need the Postgres features, they’re a liability. For example, even if you don’t use multiple user accounts, you’ll still need to configure and debug host-based authentication. You have to firewall off your Postgres server. And more features mean more documentation, which makes it difficult to understand the software you’re running. The documentation for Postgres 14 is nearly 3,000 pages.

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

#52

Post by endisneigh »

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.

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

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

#53

Post by bob1029 »

ak39 wrote: post #36

SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.

SQLite supports the best version of "stored procedures", IMO:

https://www.sqlite.org/appfunc.html

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

#54

Post by hahn-kev »

ak39 wrote: post #36

SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.

But man the maintenance and debug nightmare never seems worth it for that tradeoff. Not to mention vendor lockin

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

#55

Post by andrewstuart »

bambax wrote: post #51
andrewstuart wrote: post #23

I can’t see any valid reason not to use Postgres at the back end, unless you are in some sort of environment such as embedded or cloudflare workers that requires it. Or if you need a graph database there are better choices than Postgres. Postgres is good on multi core, incredibly feature rich, multi user, supported by everything, lightweight and has all the tools for production workload and management. All stuff that…

> I can’t see any valid reason not to use Postgres at the back end From TFA: > if you don’t need the Postgres features, they’re a liability. For example, even if you don’t use multiple user accounts, you’ll still need to configure and debug host-based authentication. You have to firewall off your Postgres server. And more features mean more documentation, which makes it difficult to understand the software you’re run…

>> you’ll still need to configure and debug host-based authentication.

False

>> you have to firewall off your server

Well yes. Are you saying SQLite servers don’t need a firewall?

>> more features/more documentation/hard to understand your software

Features lead to powerful software, documentation leads to understanding.

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

#56

Post by Xeoncross »

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…

Replace SQLite with Excel and read it again.

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

#57

Post by sodapopcan »

endisneigh wrote: post #52
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.

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

They aren't necessarily going to have all this. Lots of smaller ecom shops can run on a single server per region. If you're a North American company selling a few hundred t-shirts per day in NA and EU, it could probably be fine, no? I'll admit I'm not speaking from experience. Rather, I have experience in everything I just said only I was using pg, not sqlite. But I've been very interested in sqlite recently.

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

#59

Post by sergioisidoro »

A few years I made a decision to ship a SQLite database in an (internal) ruby on rails package. Why? Because there was a large set of (static) data that was required for the package to work, and it made no sense to make an API to query it from external sources (It wasn't that big, something like 5-10Mb if I recall). At the time it felt like a super dirty hack, but time seems to have validated that decision :)

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

#60

Post by emodendroket »

sodapopcan wrote: post #57
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

They aren't necessarily going to have all this. Lots of smaller ecom shops can run on a single server per region. If you're a North American company selling a few hundred t-shirts per day in NA and EU, it could probably be fine, no? I'll admit I'm not speaking from experience. Rather, I have experience in everything I just said only I was using pg, not sqlite. But I've been very interested in sqlite recently.

Why even build your own e-commerce Web site at all in that case? It’s undifferentiated work.
Post reply on HN