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

61–70 of 167 posts

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

#61

Post by Varriount »

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…

> It's the awful queries that do in memory sorting or make temporary tables for no reason or read-after-write, etc.

Are there any viable alternatives though? I often wonder what an SQL-like language built from the ground up would look like.

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

#62

Post by eternityforest »

matlin wrote: post #7

If you need multiple writers and can handle eventual correctness, you should really be using cr-sqlite[1]. It'll allow you to have any number of workers/clients that can write locally within the same process (so no network overhead) but still guarantee converge to the same state. [1] https://github.com/vlcn-io/cr-sqlite

I don't see any timestamps in the data. If two peers write to the same row, does it not use latest-wins logic?

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

#63

Post by endisneigh »

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.

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.

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

#64

Post by voganmother42 »

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…

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

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

#65

Post by Dan42 »

kijin wrote: post #25
morelisp wrote: post #18

Earlier quoted context omitted.

But why take on the operational overhead of a separate DB server (not to mention 200 more microseconds), plus the EC2 surcharge? I would rather run app+SQLite + dumb object storage, than app + MySQL + MySQL incremental backup and restore.

What separate DB server? I was talking about installing the RDBMS on localhost, right inside the server where your application runs. No other EC2 instance, no extra charges. Preferably connect to it over a Unix domain socket instead of TCP. That's the only way to compare SQLite performance with an RDBMS in an apples-to-apples way. The point about operational overhead makes sense, though, and IMO it's the only point i…

Thank you for saying that, it save me the trouble of writing it.

This apples-to-oranges comparison (strawman? motivated reasoning?) unfortunately makes me mistrust this entire article.

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

#66

Post by sumtechguy »

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…

SQLite fills a need in the market that postgres does not. Local single process data storage and retrieval from that with some structure. Postgres and all of the DB's like it kick in when you want more than one process involved. MS used to have Access that filled this need very nicely. Once you go multi user/process you probably do not want sqlite you will want something that can do ACID on a multi user level. Once you go more than one process to store data you can make your installation a larger burden than you really need to deal with. On the other hand I can think of maybe one or two projects where sqllite fit very nicely for a data store. Most of the other cases I had involved a 'real' db.

For this case I guess they could try to bend sqlite to do this but the pain in doing so will probably not be worth the long term trouble than just using mysql or postgres or something like those.

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

#67

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)

#68

Post by evantbyrne »

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.

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.

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

#69

Post by mattgreenrocks »

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…

I’m excited about SQLite for web apps if only because it is one less moving piece in my stack, which focuses on prototyping and finding product market fit.

If I start hitting hundreds of writes per sec, then, thats either awesome or I wrote some horrible code.

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

#70

Post by fauigerzigerk »

kentonv wrote: post #35
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…

Postgres is great at what it does, but it is extremely inefficient for storing a small amount of data, e.g. kilobytes or a few megabytes. sqlite, on the other hand, scales nicely all the way down to a few kb. This matters for cloud in that it means with Postgres you cannot take a "lots of small databases" strategy, e.g. database per user or database per document. You pretty much have to group a lot of data into one b…

>This matters for cloud in that it means with Postgres you cannot take a "lots of small databases" strategy, e.g. database per user or database per document. You pretty much have to group a lot of data into one big database.

You're right, it's a very interesting strategy. Unfortunately, last time I looked Cloudflare's D1 didn't support this approach as there was no API to create a database at runtime from Worker code. Has that changed?

Post reply on HN