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

71–80 of 167 posts

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

#71

Post by [deleted] »

endisneigh wrote: post #63
sodapopcan wrote: post #57

Earlier quoted context omitted.

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.

It’s not about the size. Issues result in lost sales which means lost revenue. You would want fault tolerance regardless of how big you are.

[deleted]

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

#72

Post by emodendroket »

evantbyrne wrote: post #68
emodendroket wrote: post #60

Earlier quoted context omitted.

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

As with anything, the typical business can use something off-the-shelf, but a certain percentage are doing things differently enough that custom development becomes practical. I had to custom build the billing system for Beaker Studio to properly meter customers. Even Stripe's metering API wasn't flexible enough to handle per-hour metering.

I find it hard to imagine a reason a shop selling 100 tee shirts in a day would need any custom functionality since this is basically the exact use case all these OOB e-commerce tools are built for.

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

#73

Post by bambax »

andrewstuart wrote: post #55
bambax wrote: post #51

Earlier quoted context omitted.

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

> Are you saying SQLite servers don’t need a firewall

I'm not the author. But I can tell you there are no "SQLite servers". That's kind of the whole point.

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

#74

Post by otoolep »

benbjohnson wrote: post #10

Author here. Cool to see the post make it up on HN again. I'm still as excited as ever about the SQLite space. So much great work going on from rqlite, cr-sqlite, & Turso, and we're still plugging away on LiteFS. I'm happy to answer any questions about the post.

Thanks Ben!

rqlite[1] creator, happy to answer questions too.

[1] https://www.rqlite.io

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

#75

Post by bootsmann »

endisneigh wrote: post #63
sodapopcan wrote: post #57

Earlier quoted context omitted.

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.

It’s not about the size. Issues result in lost sales which means lost revenue. You would want fault tolerance regardless of how big you are.

There is a cost to fault tolerance as well, if you lose $100 per month due to fault tolerance thats worth about 30 developer minutes. Do you really get good fault tolerance for 30m of monthly work?

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

#76

Post by evantbyrne »

emodendroket wrote: post #72
evantbyrne wrote: post #68

Earlier quoted context omitted.

As with anything, the typical business can use something off-the-shelf, but a certain percentage are doing things differently enough that custom development becomes practical. I had to custom build the billing system for Beaker Studio to properly meter customers. Even Stripe's metering API wasn't flexible enough to handle per-hour metering.

I find it hard to imagine a reason a shop selling 100 tee shirts in a day would need any custom functionality since this is basically the exact use case all these OOB e-commerce tools are built for.

Yeah, you're probably right about that. Main thing that would likely be custom would be the design.

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

#77

Post by benbjohnson »

maxmcd wrote: post #5

Been feeling a little miffed about this recently. Litestream is excellent but if you have multiple writers your db gets corrupted. Quite easy to do with rolling deploys. LifeFS was announced and is intended to help this. Now seems like ( https://fly.io/docs/litefs/getting-started-fly/ ) it requires an HTTP proxy so that the application can guess about sqlite write/read usage by reading the HTTP request method. This s…

Author here. The single-node restriction for Litestream was one of the main reasons we started LiteFS. There isn't a way to handle streaming backup from multiple nodes with Litestream & S3 as SQLite is a single-writer system and there aren't any coordination primitives available with S3.

I agree that many of the SQLite cloud offerings introduce the same network overhead. With LiteFS, the goal is to have the data on the application node so you can avoid the network latency for most requests. Writes still need to go to the primary so that's unavoidable but read requests can be served directly from the replica. The LiteFS HTTP proxy was introduced as an easy way to have LiteFS manage consistency transparently so you can get read-your-writes consistency on replicas and strict serializability on the primary. That level of consistency works for a lot of applications but if you need stronger guarantees then there's usually trade-offs to be made.

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

#78

Post by imhoguy »

Did anybody try something like that: read/write to SQLite database file on backend, but also allow the database file to be downloaded at any time by rich JS frontend for read-only querying. I just wonder if the file is going to be (eventually-) consistent and not corrupted.

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

#79

Post by bcrosby95 »

emodendroket wrote: post #60
sodapopcan wrote: post #57

Earlier quoted context omitted.

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.

I don't know about nowadays.

8 years ago we built our own ecommerce site + warehouse app (inventory tracking, fulfillment, receiving) for a few hundred orders per day. The goal was to be able to better see profit margins by product, track where the money was going/coming from in detail, along with cleaning up the inventory management part of the operation.

The warehouse people loved the change because it really streamlined the fulfillment process and it basically reduced their errors to zero. Owners loved it because of the all the cost/price tracking. It took about 6 months of work by 2 devs.

Before this they were on woocommerce. It was slow as shit. We looked at shopify but the integrations with 3rd party warehouse stuff was bad. The other solutions we looked at were overly complicated swiss army knives.

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

#80

Post by benbjohnson »

voganmother42 wrote: post #64
bambax wrote: post #51

Earlier quoted context omitted.

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

them citing the (excellent) Postgres documentation page count is hilarious. There is a really useful comparison to be made re: features / scope -- but approximating that and punishing a project for how comprehensive their docs are...feels like lines of code as a productivity measure but like 10x less accurate or useful lol

Author here. My goal in the comparison was only in terms of scope, not that Postgres folks should be penalized for having good documentation. I think Postgres is great and it makes sense to use it when it's called for. But I think it can be overkill for many projects.
Post reply on HN