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

SQLite is not a toy database

antonz.org

Post reply on HN
Print view View original

101–110 of 364 posts

Re: SQLite is not a toy database

#101

Post by spaniard89277 »

jacurtis wrote: post #54
unnouinceput wrote: post #29

Earlier quoted context omitted.

At the time when WordPress rolled out SQLite was still in its infancy while MySQL was already a mature DB, hence the choice. These days however they could, at least, do a nice wizard to ask "do you want to run a blog only?" and deploy SQLite instead.

I don't have any data on this, but I do know that a significant (if not majority) of Wordpress sites now aren't even blogs. They are small websites for things like restaurants, hair salons, construction companies, photographers, and personal portfolios. Especially since most of these sites are also running on $3/mo shared hosts, switching to SQLite would be a substantial improvement. Most these sites are running a ho…

You don't even need SQLite for that. Something like PicoCMS with markdown files is more than enough. If you want a fronted for the owner, that's another story, but if you're the one mantaining the sites, WordPress is an overkill 99% of the time.

Re: SQLite is not a toy database

#102

Post by re »

D13Fd wrote: post #49

My only "problem" with SQLite was that it was so fast, running locally, that it hid just how much my app was needlessly hitting the database. It was a surprise when I transitioned to a networked Postgres server and performance completely tanked due to my crappy code...

I know you put "problem" in quotes, but in case you haven't seen it, this document was posted here a little while ago: https://sqlite.org/np1queryprob.html

It describes how access patterns that would be bad practices with networked databases are actually appropriate for SQLite as an in-memory DB.

Re: SQLite is not a toy database

#103

Post by tmountain »

nalgeon wrote: post #51
ben509 wrote: post #16

> There is a popular opinion among developers that SQLite is not suitable for the web, because it doesn’t support concurrent access. No, the issue is it doesn't have high availability features: failover, snapshots, concurrent backups, etc. (Edit: oops, comment pointed out it does have concurrent backups.) SQLite isn't a toy DBMS, it's an extremely capable embedded DBMS. An embedded DBMS is geared towards serving a si…

I think that the absence of 'high availability' is not an issue for small websites or web apps. Transactions are ACID, concurrent readers are fully supported. Backups and administrative tasks are super-easy.

How do backups work? Is there a locking mechanism to prevent file corruption if the file is copied during writing?

Re: SQLite is not a toy database

#104

Post by zokier »

_0w8t wrote: post #60
II2II wrote: post #42

Earlier quoted context omitted.

One of the disappointing developments of the past quarter century is the near demise of general purpose databases as an end user application. Yes, client/server models are useful when dealing with a large number of transactions. On the other hand, it is usually too complex to justify for personal or small office use. I miss the days when databases were included in office suites or could be purchased as relatively ine…

Access DB is still included in Microsoft Office

And LibreOffice has Base, a sadly often neglected component.

Re: SQLite is not a toy database

#105

Post by api »

petercooper wrote: post #30

With no sense of overstatement here, SQLite is one of my favorite creations in the entire world, so I have a bunch of links some of you might find interesting if you want to dig further: https://github.com/sql-js/sql.js - SQL.js lets you run SQLite within a Web page as it's just SQLite compiled to JS with Emscripten. https://litestream.io/blog/why-i-built-litestream/ - Litestream is a SQLite-powered streaming replica…

SQLite is one of those things that also shows by contrast how bloated and inefficient much of modern software is. It accomplishes so much so efficiently with such a small footprint.

Re: SQLite is not a toy database

#106

Post by SahAssar »

voxic11 wrote: post #56
nalgeon wrote: post #51

Earlier quoted context omitted.

I think that the absence of 'high availability' is not an issue for small websites or web apps. Transactions are ACID, concurrent readers are fully supported. Backups and administrative tasks are super-easy.

Also if you really need HA there are nice projects like https://dqlite.io/

Looking at https://dqlite.io/docs/protocol it seems like it does not allow for embedded usage though. Doesn't this turn it into more of a traditional client-server RDBMS?

Re: SQLite is not a toy database

#107

Post by anticristi »

midrus wrote: post #39
michaelmcmillan wrote: post #19

I've built a complex CRM that handles 2.1 million USD in transactions every year. It is running sqlite with a simple in-memory lru cache (just a dict) that gets purged when a mutating query (INSERT, UPDATE or DELETE) is executed. It is very simple and more than fast enough. Friendly reminder that you shouldn't spend time fine tuning your horizontal autoscaler in k8s before making money.

Do you mean I don't need Go microservices talking gRPC deployed in multiple kubernetes clusters with bash script based migrations via GitOps with my hand made multi cloud automation (in case we move clouds) following all the SCRUM practices to ship working software? Mindblowing.

> my hand made multi cloud automation (in case we move clouds)

Aren't these symptoms of a deeper problem? Many Product Manager I talk to wanted me to build something that is as flexible as possible and solves all problems for everyone, everywhere. Go microservices with gRPC and Kubernetes feels like the only high-level technical decisions I can take in light of such information. :)

Re: SQLite is not a toy database

#108

Post by haolez »

petercooper wrote: post #30

With no sense of overstatement here, SQLite is one of my favorite creations in the entire world, so I have a bunch of links some of you might find interesting if you want to dig further: https://github.com/sql-js/sql.js - SQL.js lets you run SQLite within a Web page as it's just SQLite compiled to JS with Emscripten. https://litestream.io/blog/why-i-built-litestream/ - Litestream is a SQLite-powered streaming replica…

Wow! The sql.js bundle is only 8kb. This is a hidden gem for sure. Thanks for pointing it out!

EDIT: It's actually 1.2MB. Thanks for pointing it out :)

Re: SQLite is not a toy database

#110

Post by godot »

spaniard89277 wrote: post #101
jacurtis wrote: post #54

Earlier quoted context omitted.

I don't have any data on this, but I do know that a significant (if not majority) of Wordpress sites now aren't even blogs. They are small websites for things like restaurants, hair salons, construction companies, photographers, and personal portfolios. Especially since most of these sites are also running on $3/mo shared hosts, switching to SQLite would be a substantial improvement. Most these sites are running a ho…

You don't even need SQLite for that. Something like PicoCMS with markdown files is more than enough. If you want a fronted for the owner, that's another story, but if you're the one mantaining the sites, WordPress is an overkill 99% of the time.

Pleasantly surprised to hear PicoCMS mentioned here, since it's not typically the most common PHP markdown CMS of choice folks like to mention.

I was a casual developer (i.e. not for work, just for personal) deep into the PicoCMS ecosystem for a couple years, a few years ago. I both started a site and helped a family convert an old static site to PicoCMS and really had no complaints. Re: frontend for the owner, I started with Pico Admin and made a bunch of modifications to it (including an image uploader) and the non-tech owner has no complaints and it's been working well since.

Nowadays for my own blog I'm into the whole SSG/JAM trend, but I'd still run a PicoCMS site any time, if the use case is right.

Post reply on HN