TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why you should probably be using SQLite

353 pointsby rrampageover 1 year ago

60 comments

minimaulover 1 year ago
For an app running on one VPS? Sure, this might make a decent amount of sense.<p>But... for an app running multiple instances, the article suggests a lot of extra complexity. Managing that complexity makes less sense to me than just firing up a managed database server (RDS, or whatever).<p>Even if you&#x27;re self hosting, I think running a MySQL&#x2F;Postgres cluster is a lot less complex than the options this article calls out.<p>edit: and more to the point - MySQL &#x2F; Postgres replication is <i>boring</i>. It&#x27;s done by a ton of deployments, and isn&#x27;t going to surprise you, at least at smaller scale.
评论 #38038025 未加载
评论 #38038109 未加载
评论 #38048216 未加载
评论 #38038791 未加载
评论 #38040183 未加载
评论 #38046796 未加载
评论 #38042615 未加载
codedokodeover 1 year ago
SQLite is not easy to use with migrations, because it doesn&#x27;t support many ALTER TABLE options [1]: you need to create a new table instead of modifying a column, for example. Also, foreign keys are ignored by default and you need to explicitly enable them after connecting.<p>Also, column types are not checked and you can easily insert a string into numeric column.<p>Also it doesn&#x27;t allow you to use multiple application servers.<p>So it can be used only with small, simple sites.<p>[1] <a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;lang_altertable.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.sqlite.org&#x2F;lang_altertable.html</a>
评论 #38037814 未加载
评论 #38040012 未加载
评论 #38038103 未加载
评论 #38038368 未加载
评论 #38038672 未加载
评论 #38037848 未加载
评论 #38037831 未加载
评论 #38039092 未加载
Ensorceledover 1 year ago
One thing I don&#x27;t get ... are people really having problems getting PostgreSQL, or even MySQL, up and running? Is this REALLY a dev&#x2F;devops&#x2F;ops hurdle for people?<p>Just seems strange that is actually a problem.<p>Don&#x27;t get me wrong, I use SQLite ... it&#x27;s just not the database for my company&#x27;s management web portal.
评论 #38038002 未加载
评论 #38039091 未加载
评论 #38037982 未加载
评论 #38037889 未加载
评论 #38037862 未加载
评论 #38037993 未加载
评论 #38038681 未加载
评论 #38039130 未加载
评论 #38038624 未加载
评论 #38043941 未加载
评论 #38038156 未加载
评论 #38038560 未加载
xnorswapover 1 year ago
Saying that something has &quot;Zero latency&quot; because it&#x27;s &quot;on disk&quot; is off-putting from a technical honesty perspective.
评论 #38037624 未加载
评论 #38037671 未加载
评论 #38037566 未加载
评论 #38039023 未加载
评论 #38039158 未加载
评论 #38039234 未加载
评论 #38038422 未加载
password4321over 1 year ago
Kent is HN&#x27;s Steve Gibson (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37999197#38001051">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37999197#38001051</a>) of full stack development.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35903878#35915789">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35903878#35915789</a><p>&gt; <i>Kent is the only blogger that I&#x27;ve felt compelled to tell all my less experienced colleagues to completely ignore</i>
评论 #38039226 未加载
segfaltnhover 1 year ago
Saying it&#x27;s not uncommon for a database to be tens or even hundreds of milliseconds away is ignorant at best. If you care about performance, you&#x27;re not jumping across the US for every database query.<p>Honestly this is the kind of stuff written to fluff out a social presence and offers nothing to a technical audience.
masfoobarover 1 year ago
There could&#x2F;can be cases to use SQLite over SQL Server, MySQL, Postgres, etc. It really comes down to reasoning with the problem.<p>For me personally, I have only used SQLite for 2 scenarios.<p>1) When developing. SQLite is a simple method to getting something together, before building a proper MySQL&#x2F;SQLServer&#x2F;Postgres one.<p>2) Client software. Some client software needs a temporary data store and find SQLite great for this. These are not complicated databases. They barely have about 5 tables. Nothing more than a Queue system than anything, which goes over the wire via Rest API to a Messsaging Queue. Once sent over with a reply of &quot;success&quot; - it is removed from SQLite. It is a nice, simple system.<p>There can be a few other reasons.<p>Other than the above, I don&#x27;t think I would be confident of SQLite file for a moderately sized database, likely to be used for some web portal or CMS system we created where more than one request could be talking to the database at the same time. This is why you should stick to those central, relational databases.<p>MySQL and Postgres, especially, are not that difficult to install, whether on the same system or its own dedicated server.<p>I hope my comment is not seen as a negative for SQLite. If anything, my attitude is the opposite. I really like the work and effort that has gone into SQLite. A virtual pat-on-the-back by those involved! It is a great approach to having data in 1 file, rather than writing your own.. or having lots of &quot;records&quot; in their own files (in a directory) which I have done.
评论 #38039276 未加载
beoberhaover 1 year ago
SQLite is an awesome tool, but I wish we’d stop trying to force it into situations it wasn’t made for. It doesn’t belong anywhere near a web app deployment that currently or will span two or more machines. Once you have a “distributed system” and the complexities of a DR scenario, reach for a tool that was built for such. You can’t go wrong with PG&#x2F;MySQL. You can go very wrong with a VC-hyped replicated file system from a company known for outages.
评论 #38040614 未加载
评论 #38039712 未加载
评论 #38042906 未加载
评论 #38038611 未加载
Ilaskyover 1 year ago
I’ve been using Pocketbase[0] on my projects and I can’t recommend it enough.<p>It is built on a SQLite db and has real-time pub&#x2F;sub capabilities. Its JS SDK is incredibly easy to use and setup for CRUD as well. For side projects and some medium tasks, I’d say SQLite&#x2F;Pocketbase has been super easy to work with.<p>[0] <a href="https:&#x2F;&#x2F;pocketbase.io" rel="nofollow noreferrer">https:&#x2F;&#x2F;pocketbase.io</a>
wg0over 1 year ago
One possible strategy is to have one directory&#x2F;file per customer which is one SQLite file. But then as the user logs in, you have to look up first what database they should be connected to.<p>OR somehow derive it from the user ID&#x2F;username. Keeping all the customer databases in a single directory&#x2F;disk and then constantly &quot;lite streaming&quot; to S3.<p>Because each user is isolated, they&#x27;ll be writing to their own database. But migrations would be a pain. They will have to be rolled out to each database separately.<p>One upside is, you can give users the ability to take their data with them, any time. It is just a single file.<p>[0]. <a href="https:&#x2F;&#x2F;litestream.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;litestream.io&#x2F;</a>
评论 #38048232 未加载
wave84over 1 year ago
As a guy running a few Debian web servers for some small client projects and a few personal projects (some of which are medium sized, e.g. a website that gets 10 million pageviews &#x2F; month) I actually tried to move from MariaDB to SQLite. The idea seemed great, at least in theory. Mainly to get away from mysqld, which actually crashed on me and corrupted some data once or twice in a timespan of 15 years.. think it was due to package updates every time.<p>Anyway, query and app logic modifications aside, I quickly ran into two unsolvable issues for me.<p>1. The lack of a robust web based admin tool comparable to phpmyadmin (no, phpliteadmin doesn&#x27;t even come close) 2. No alter table. This hit pretty hard.<p>Plus lots of other idiosyncrasies - no enums, no type for dates, etc. In the end I decided it&#x27;s not worth the extra work, trouble and risks and stayed on Maria.
评论 #38041674 未加载
评论 #38086701 未加载
jimbokunover 1 year ago
I&#x27;m finding Sqlite DBs in S3 to be a great solution for ETL tasks.<p>It&#x27;s a project where multiple other applications want to process data produced by my application. Instead of forcing them to make API calls to retrieve all of the data and all the network overhead and latency that entails, periodically write Sqlite DBs to S3 and post an event that the database is available. Can create one database per customer, or whatever your natural partition key is. Then it&#x27;s just pull the database to local disk, pull all the data you need with SQL queries, and delete from the bucket when every client has had a chance to process it.<p>I believe it offers much better throughput than going through an API.
bob1029over 1 year ago
The following is our current strategy. We used to be all-in on SQLite but we have discovered some nuance as we grow. We do B2B SaaS&#x2F;PaaS for banking sector.<p>If we have a customer that is OK with RPO measured in minutes-to-hours and they have fewer than 5k active users, we are perfectly happy running with SQLite on a customer-managed VM and instructing them to use snapshots for backup &amp; restore. Everything on one simple cheap VM in Azure&#x2F;AWS&#x2F;on-prem. One storage volume to snapshot. No weird tricks.<p>If the customer demands stronger consistency between their underlying record system and our system (specifically at time of catastrophe) and&#x2F;or has more than 5k active users, then we are starting to push towards a separate cloud-native stack. Azure SQL Server Hyperscale with geographic replication to another region within ~100ms of the primary region. I looked long &amp; hard at some of the SQLite replication options, but there is no way in hell I could get them to pass due diligence with the kinds of CTOs I have to argue with regularly.<p>SQLite is incredible for keeping it light &amp; simple, and we still advocate for this where it fits the overall technical strategy. In terms of performance, before you reach a certain breakpoint, it is very hard to beat SQLite. You have to do it wrong on purpose to make it slower than a single node hosted solution on equivalent hardware.
aaviator42over 1 year ago
I&#x27;m a huge fan of SQLite! My org&#x27;s apps use it heavily, often via this simple key-value interface built on sqlite: <a href="https:&#x2F;&#x2F;github.com&#x2F;aaviator42&#x2F;StorX">https:&#x2F;&#x2F;github.com&#x2F;aaviator42&#x2F;StorX</a><p>Handles tens of thousands of requests a day very smoothly! :)<p>As an aside, has anyone tried using a RAM-disk as the storage medium for SQLite DB files? We&#x27;ve started experimenting with it lately and results have been promising!
评论 #38038342 未加载
评论 #38038095 未加载
评论 #38049253 未加载
AYBABTMEover 1 year ago
SQLite is cute and very appropriate in certain cases:<p><pre><code> - Local storage for a mobile&#x2F;desktop app, instead of a DIY file type. - Local cache storage for a distributed system, instead of a DIY file type. </code></pre> While you can use it as a general backend, and some people work hard to make it usable in distributed systems, it continues to be a fancy elaborate project to turn SQLite into something it isn&#x27;t. It&#x27;s a thought experiment that happens to get corporate funding. It&#x27;s fun and interesting in the same way as Dogecoin is.<p>There&#x27;s plenty of free DBaaS these days that are frankly incredible and FREE. I work for one, so might sound like I&#x27;m chilling that space. But I recently went to work for one exactly because I think the new offerings are an incredible leap forward in developer productivity, and there&#x27;s a lot of cool stuff to be done here. I could instead have gone to work for one of those who are working on SQLite, but I just don&#x27;t believe they&#x27;re real products for real web workloads. They&#x27;re a marketing catch for curious learners and experimenters. I respect the intellectual curiosity but it&#x27;s not how I would build anything.
评论 #38040996 未加载
评论 #38041016 未加载
happyweaselover 1 year ago
&gt;the entire database is &gt;in a single file<p>Microsoft Access since at least 30 years? MdB file? Accessible with various dB APIs? And wasn&#x27;t dBASE also the same thing?
评论 #38038765 未加载
评论 #38043946 未加载
fb03over 1 year ago
I don&#x27;t know what SQLite has gotten over a 5 line docker-compose.yml running PG locally for my project. It&#x27;s ready for scale-up when needed, supports more features and foreign keys without setting a flag manually, proper types etc.<p>I get SQLite for mobile and toy projects but really, a PG set up in docker-compose.yml in your project is the easiest thing to do these days.
评论 #38038052 未加载
endisneighover 1 year ago
Sure if you don’t care about consistency use litefs smh.<p>You’re going to end up creating a cobbled mess and were better off using a server side database
chasilover 1 year ago
I actually get to see a little more of databases than most so:<p>&quot;SQLite is a sql-based database with a particularly unique feature: the entire database is in a single file.&quot;<p>Digital Equipment Corporation (DEC) developed a SQL database known as Rdb for VMS. It could store everything in a single file. Oracle bought it, and maintains it here:<p><a href="https:&#x2F;&#x2F;www.oracle.com&#x2F;database&#x2F;technologies&#x2F;related&#x2F;rdb.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.oracle.com&#x2F;database&#x2F;technologies&#x2F;related&#x2F;rdb.htm...</a><p>SQLite&#x27;s ATTACH command allows the spanning of files. Be careful how you use it in WAL mode.<p>&quot;SQLite being a file on disk does make connecting from external clients effectively impossible.&quot;<p>SQLite does support access over NFS and SMB, unless you are in WAL mode.
skybrianover 1 year ago
Seems like this assumes you <i>have</i> a local disk, which isn&#x27;t true for &quot;serverless?&quot;
评论 #38037921 未加载
评论 #38039106 未加载
评论 #38037598 未加载
xenophonfover 1 year ago
If I was going to give folks advice, it would be to use an ORM, instead. That let me build low-investment prototypes using SQLite. When I outgrew it, I could easily switch to PostgreSQL by adding the appropriate test framework plugin and changing the database connection string.<p>SQLite, for all it&#x27;s features, has some pretty significant limits. In my case, I needed better date&#x2F;time and decimal type handling than what&#x27;s on offer in SQLite. I still test my code against SQLite because that is a useful way to lint my data model—plus it&#x27;s nice for small-scale proof-of-concept deployments—but I expect deployers to use PostgreSQL or MariaDB in production.<p>Edit: I&#x27;ve had a chance to read the article. The comment about &quot;zero latency&quot; is wrong because it ignores disk I&#x2F;O. And yes, I know SSDs are super fast. Still not zero. The bit about Docker Compose rings hollow. It sounds like they need to learn how to use multiple Compose files, e.g., <a href="https:&#x2F;&#x2F;mindbyte.nl&#x2F;2018&#x2F;04&#x2F;04&#x2F;overwrite-ports-in-docker-compose.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;mindbyte.nl&#x2F;2018&#x2F;04&#x2F;04&#x2F;overwrite-ports-in-docker-com...</a>. As for development and testing, mock database setup should be handled by your unit test framework. I&#x27;m familiar with pytest, which makes testing the same model or ETL across multiple database fixtures very, very easy. SQLite has nothing to do with that.
015aover 1 year ago
I see posts like this and I can&#x27;t help but think: This sounds exactly like something an academic would recommend, and then you hit the reality of industry engineering.<p>Its a similar take to a lot of the negativity surrounding Next 14&#x27;s stabilized server actions. The negativity is academic; the productivity is industrial.<p>Here&#x27;s my counter-hype take: SQLite actually kind of sucks. It has a place, but that place isn&#x27;t significantly different from where it was five years ago despite all the &quot;serverless read replicated VC funded hacker news hype startups&quot; work that&#x27;s happened since then.<p>If you&#x27;re in crazy-enterprise hell-engineering; no one is going to reach for SQLite when more robust alternatives like Postgres exist.<p>If you&#x27;re trying to get something out the door fast, you&#x27;ve got Postgres on Supabase, you&#x27;ve got MySQL on Planetscale, you&#x27;ve got Firebase, fifteen years of database-platform development, all of these aren&#x27;t just cheap, they&#x27;re free, and zero maintenance, you&#x27;re not going to pay more money to do more work for a worse product by setting up SQLite on your single DigitalOcean VPS. You probably won&#x27;t even reach for something like Cloudflare D1; sure, its <i>interesting</i>, but why? Its just Planetscale, but not better in any way and worse in plenty (its not even really much cheaper).<p>SQLite doesn&#x27;t support alter table. It doesn&#x27;t have a date-time type. It doesn&#x27;t enforce columnar types outside of strict mode, which isn&#x27;t enabled on e.g. Cloudflare D1. Someone stop me. Everyone says &quot;KISS, you can get so much performance out of one application server with SQLite running locally&quot; but you can get the same f^cking performance out of one application server, and a DBaaS, like Planetscale, and its easier, and its cheaper, and you get backups, and you get full MySQL, and you get a paved-road to actually paying them $30&#x2F;mo if you need to instead of hitting a bottleneck and suddenly having to wonder how the hell you&#x27;re going to scale SQLite beyond this one instance (&quot;we need VC funding for more engineers&quot;, you&#x27;ll think in that moment)<p>Kent&#x27;s statement &quot;However, SQLite is capable of handling databases that are an Exabyte in size&quot; actually makes me mad. Its <i>so ridiculously academic</i> I&#x27;m aghast anyone takes this seriously. &quot;Oh, well, hc-tree uses 48 bit page numbers so its an exabyte, and you&#x27;ll hit other application problems first anyway&quot;. No; you&#x27;ll hit problems with SQLite first, ten times out of ten, it&#x27;ll be long before you hit an exabyte, it&#x27;ll be before you even hit 100gb.*
steve_adams_86over 1 year ago
I’ve helped too many teams migrate from SQLite (after a ton of growing pains and suffering from tech debt) to agree with this.<p>I think SQLite is awesome for some things. It’s also hard to beat in some cases. But if you use it in a non-ideal situation, you need to know when, why, and what your refactor path will be to get to the right technology. And there should be a good reason for doing that, and I can’t think of one that makes sense.<p>The teams I helped often said something to the effect of “SQLite is great because it got us this far!”, and while I appreciate the optimism, they wouldn’t have gone a shorter distance with MySQL or Postgres. They made the wrong choice, period, and lost a huge amount of productivity to it.<p>Yet there are people out there who have chosen something like firebase where SQLite would be perfectly fine and far simpler, too. I love SQLite, but I think it’s promoted incorrectly at times. It makes for some brutal growing pains when it’s used in the wrong places.
评论 #38039439 未加载
whateveracctover 1 year ago
<p><pre><code> config.services.postgresql.enable = true; </code></pre> ^ NixOS one-liner to get a local Postgres going. I tried SQLite for a single VPC startup MVP but then just used Postgres because it was just as easy and it&#x27;s just better to build backend software with.<p>And then when it made sense to use a managed Postgres instance, it was trivial to migrate.
pphyschover 1 year ago
The first two items are just wrong. I use PostgreSQL like SQLite all the time. That is: Colocated with the application, connected only via UNIX socket. In these cases, the database is <i>not meant</i> to be a separate application, so I don&#x27;t treat is as something separate.<p>Ironically, this is also the easiest way to set up PostgreSQL. At least in the distributions I use, it is already configured to connect locally over UNIX sockets, and all I have to do is create a system user to connect with.<p>PostgreSQL has a bad reputation for being difficult to set up because people expect it to be exposed on the network by default, and then they have to dig into the obscurely named pg_hba.conf and change multiple lines.<p>There is ongoing cargo cult wisdom that &quot;the RDBMS HAS to be a standalone service&quot; which is just nonsense and extremely counterproductive for the median use case.
frithsunover 1 year ago
Funny this article would pop up for me today, as I&#x27;m currently migrating my web app from sqlite to mysql.<p>I got jazzed up on articles like this, only to figure out the hard way that it&#x27;s ill-suited to apps where concurrency matters.<p>Sqlite is an incredible piece of software, but it doesn&#x27;t do scalable, concurrent things well.
评论 #38043125 未加载
评论 #38039691 未加载
评论 #38040090 未加载
hermitcrabover 1 year ago
I have a desktop app that stores all it&#x27;s info in a single XML. The XMl file is read into memory and written to disk when they save. I lock the XML file so that only user can have it open to write. Customers never need more than a few thousand records and it works fine. <i>But</i> some of my customers want to be able to read&#x2F;update data from more than one PC&#x2F;Mac on a local network. Performance requirements are low (generally &lt;10 concurrent users and &lt;1 update per second). I don&#x27;t want to use a heavtwight database. I wondered if SQLite could be a way to handle this? But the SQLite FAQ seems to have quite a few caveats about accessing it from multiple processes across a network. Or is there a simpler&#x2F;more reliable way to transition a single-user app to multi-user?
评论 #38045390 未加载
评论 #38041644 未加载
dbrgnover 1 year ago
SQLite is great, but the article misses the greatest weakness: It is almost entirely untyped. Feel free to specify fancy types for your columns. But SQLite doesn&#x27;t care in the least. You can create an INTEGER column and write text to it. Or bytes. Or anything you&#x27;d like!<p>The other thing I miss often is better support for schema migrations. For a lot of things (like adding certain constraints after table creation) the &quot;create new table, copy data over, delete old table&quot; workaround is needed. However, it&#x27;s only a minor annoyance, and if it allows the codebase to be more maintainable, that&#x27;s OK with me (given the fantastic quality track record of SQLite).
评论 #38039751 未加载
Aurornisover 1 year ago
I think this speaks more to the target audience of the courses he sells:<p>&gt; So, can you use SQLite? For the vast majority of you reading this, the answer is “yes.” Should you use SQLite? I’d say that still for the majority of you reading this, the answer is also “yes.”<p>If you’re making a simple proof of concept app, a side project you just need to get working, or a toy project for learning then SQLite will be fine.<p>If you’re trying to learn how to build maintainable web apps for a business, getting PostgreSQL or MySQL or similar up and running shouldn’t be that big of a hurdle.<p>He also either doesn’t understand the limitations and complexities of using SQLite (migrations, foreign key quirks, other issues mentioned in this thread) or he’s deliberately ignoring them because it would weaken his point.<p>For what it’s worth, we’ve had to un-teach some of this author’s material to junior devs after they read into it a little too literally. He likes to push his way as the “right” way to do things, which can turn into a cargo cult mentality for junior devs buying his courses. He pushes his new “Epic web stack” in the same way.
qwertoxover 1 year ago
I&#x27;m logging traffic data (IP-pairs and packet+byte-count) into a SQLite database on a couple of machines, and what bothers me is that I&#x27;m unable to query them whenever I want. So the files end up being rotated whenever I want to inspect one closer.<p>While it&#x27;s good to have a simple storage solution, it does have its drawbacks.<p>Then again, yesterday I was working a bit with MBTiles, which are SQLite databases with per-z,x,y-protobuf-blocks of vector data, and in that case it does make sense to use SQLite. Or the things browsers use them to store bookmarks and stuff.
评论 #38040148 未加载
incomingpainover 1 year ago
My typical process of why I don&#x27;t ultimately use sqlite.<p>Before any DB, you&#x27;re trying to just do it all in memory.<p>Then we get to storing for persistence and going from memory -&gt; pickle -&gt; disk file is pretty quick; but we know a real DB is needed.<p>So you deploy sqlite3 and it&#x27;ll work amazingly right up until the dreaded:<p>SQLITE_ERROR: &quot;database table is locked&quot;<p>and now you&#x27;re not on sqlite3 anymore.
jarrell_markover 1 year ago
Started a Minimum Lovable Product last week that helps people work through their anxieties or fears.<p>Using SQLite as a backend for everything from session management to logging. No elk stack, no separate db. Just a single file.<p>Development is so simple so far. Maybe I’ll need to move off of it later, but who knows maybe not. And the speed of development and simplicity is what matters more now.<p><a href="https:&#x2F;&#x2F;bravesteps.love" rel="nofollow noreferrer">https:&#x2F;&#x2F;bravesteps.love</a>
clarkmoodyover 1 year ago
Coming from a Rust perspective, I really value strong typing, so the SQLite type system leaves some things to be desired.<p>Is there an alternative embedded database with stronger types?
评论 #38039685 未加载
评论 #38039350 未加载
评论 #38040134 未加载
Cthulhu_over 1 year ago
Doesn&#x27;t multi-instance replication (the article mentions LiteFS and Turso, I also know about RQLite and DQLite) negate the &quot;one less service&quot; heading?
munk-aover 1 year ago
Postgres is so incredibly easy to setup and has really low system requirements for simple applications and small quantities of data. SQLite has some really interesting features when it comes to portability - it&#x27;s a great solution if you want to be able to trivially bundle your application and data state together and distribute it as a binary... but the barrier to running a postgres instance is incredibly low.
评论 #38038869 未加载
josegonzalezover 1 year ago
Who wrote this, an SQLite vendor?<p>On a serious note, there is definitely a time and a place for SQLite - it&#x27;s a great technology - but the engineering being done to make it scalable across multiple servers etc. seems ill-placed. For applications of moderate complexity or scale, I suspect developers will quickly see issues trying to monitor and interact with SQLite in ways that they wouldn&#x27;t with other tech.
thrownaway561over 1 year ago
SQLite is the MSAccess of this generation. MSAccess was an absolutely wonderful database when you were hosting multiple small sites on a server and wanted quick deployment, easy setup and segregation. It connected easily with ODBC to a website and was robust and feature rich enough for hobby projects. They was no way I would want to bet the farm on it for a enterprise project.
评论 #38041774 未加载
matharminover 1 year ago
SQLite is by far my favorite database for any client-side application - mobile and desktop (and perhaps embedded). I still wouldn&#x27;t use it server-side for anything serious.<p>While you can do it, especially with tech such as LiteFS, I much prefer using database systems with built-in support for replication, failover, and splitting data storage from the app server.
d1lover 1 year ago
This is just yet another attempt to piggyback off the HN crowd&#x27;s enthusiasm for Sqlite in order to advertise fly.io.
评论 #38042597 未加载
siliconc0wover 1 year ago
For side projects or non-prod environments where a single instance is fine, I use sqlite + litestream and it works reasonably well. I&#x27;ve looked into the more complicated setups with LiteFS&#x2F;Consul&#x2F;RAFT and at that point I&#x27;m not sure you&#x27;re saving yourself much headache over running your own DB.
boring_twentiesover 1 year ago
I want to love sqlite but its lack of support for 64-bit unsigned integers has been frustrating to say the least.
kosolamover 1 year ago
I will comment on each point:<p>Zero Latency - irrelevant for 99% of use cases One Less Service - premature optimization - saves almost nothing Multi-instance replication - where is the advantage over say postgres? Database size - irrelevant for 99% of use cases today Development and Testing - no advantage here
mgaunardover 1 year ago
A database is essentially a server synchronizing access to the filesystem.<p>Except in the case of sqlite, which is serverless and relying on the filesystem itself for synchronization.<p>In theory it&#x27;s going to be worse, though if there is low contention you might have some latency advantages due to not having the server hop.
WuxiFingerHoldover 1 year ago
It&#x27;s always much easier to work with fully hosted turnkey-ready solutions like Supabase, Planetscale, Neon, or the like. And you get all of their huge benefits. Latency of some ms are hardly an issue for most of the use cases.<p>So, no, you should probably <i>not</i> be using SQLite.
laurent123456over 1 year ago
Is that our monthly &quot;you should always use SQLite except when you should not&quot; article?
timzamanover 1 year ago
This post is incredibly untechnical
PeterZaitsevover 1 year ago
SQLite is great, the article is not. The author seems to be compiling bunch of marketing claims and tries to sell it as a best practices. Anyone seend Exabyte sized SQLite databases in production ?
thelastgallonover 1 year ago
Mongo DB Is Web Scale: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=b2F-DItXtZs">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=b2F-DItXtZs</a>
wackgetover 1 year ago
Does SQLite have any good RDBMS programs which support it?<p>MySQL has the excellent SQLYog which is like a better version of MySQL Workbench.
评论 #38040053 未加载
georybover 1 year ago
I&#x27;d like SQLite to run on client side with persistency.<p>Not specific to SQLite itself, but that would enable a lot of uses for it.
评论 #38040161 未加载
throwawaaarrghover 1 year ago
This post would have said &quot;MongoDB&quot; years ago, and soon one will say &quot;Postgres&quot; instead, and then after that whatever&#x27;s trendy next. Probably CSV files.<p>You should probably be <i>architecting your application to use the data management solution that fits your use case</i>.
J_Shelby_Jover 1 year ago
Honest question from someone currently in the middle of implementing my first SQLite deployment for a local data store in a desktop application (and is rather new to software development.)<p>Is SQLite not ergonomic? I’ve previously played with mongodb through work and it was super simple and intuitive. But SQLAlchemy is super verbose and not at all intuitive despite being intellectually easy to grasp. It feels to me like it has decades of cruft built into the syntax and while I can appreciate that it means options it has not at all been nice to work with. I understand the issues with mongodb, but I managed to get it working in 30 minutes. Meanwhile, I’m 3 days into trying to get SQLAlchemy working. It feels to me that perhaps there may be a hole in the market for “GPT” friendly databases. Because SQLAlchemy is so verbose it kills the context window of GPT lmao.
评论 #38038985 未加载
评论 #38040180 未加载
miohtamaover 1 year ago
Why you should not use SQLite:<p>Does not handle concurrent writers
评论 #38040743 未加载
评论 #38040207 未加载
评论 #38038719 未加载
frudover 1 year ago
I can&#x27;t believe that video games still have a &quot;saving data. Please do not turn off your computer&quot; like two-phase commit hasn&#x27;t been a thing since 1987.
pjmlpover 1 year ago
Sure, if the website is a basic one.
zzo38computerover 1 year ago
&gt; SQLite being a file on disk does make connecting from external clients effectively impossible.<p>Not quite impossible (if you design an appropriate VFS), but it doesn&#x27;t work as well as a real client&#x2F;server database, since SQLite is not designed for this use.<p>&gt; SQLite does not support enums which means you&#x27;re forced to use strings. ... The main drawback to this is when it comes to the typings for the client which doesn&#x27;t allow you to ensure all values of a column are only within a set of specific possible values for the string.<p>In SQLite you can use CHECK in a table definition to require all values of a column within a set of specific possible values.<p>However, I think there are some actual flaws in SQLite, such as:<p>1. It uses Unicode (but only partially; case-insensitive is only with ASCII). This can make it less efficient than it should be if you are dealing with ASCII only, and makes it difficult (and somewhat inefficient) to deal with non-Unicode text. Although it is possible to store non-Unicode text in a TEXT value or in a BLOB value, and to use CAST everywhere or to override the built-in functions with your own, neither is really ideal, for several reasons (including causing some optimizations to not work, making your code even longer and less efficient, etc). It is also possible to patch SQLite to do this, but then if you upgrade, you must patch that one too.<p>2. The URI file name mechanism is a bit messy. Using a separate argument for the parameters might be less messy.<p>3. There is no standard way to define the time zone used for functions that deal with local time. (You can override the function to find the current time by the VFS, but overriding conversion to local time is only possible by use of an undocumented function (which is not guaranteed to stay the same in future versions).) Better (in my opinion) would be to add such a function into the VFS (since the current time function itself is in the VFS anyways, so it should go together).<p>4. It might have been better to store the journal in the same file as the database. One idea how this might be done: Set the read version to 1 and the write version to 3. If you begin a write transaction, lock the database and then make copy-on-write of any modified pages into free pages, but do not change the references to the free pages in the header (so other programs still believe they are free). To commit a transaction, make a table of the required page linking changes in the file, and then temporarily change the read version to 3, and then change all of the links (so that the pages containing the old data would now be considered free), and then change the read version back to 1 (the write version will still be 3) and then unlock the file. To roll back a transaction, simply unlock the file (which will be done automatically if the program crashes); there is no need to write or delete any file. However, one disadvantage of this method is that the database file is now up to twice as big (depending on how many pages need to be modified for each transaction), and there may be other disadvantages too.<p>5. You need file names (which is necessary for separate journal files, anyways). However, in my opinion it might be better to pass file descriptors or stream objects. (SQLite and some other libraries annoy me that they do not do such a thing, and require file names.)
bborudover 1 year ago
I always use SQLite as the first database when I start a new project. It is a great way to get started quickly and not waste time while you are figuring out what problem you are solving and how you want to structure your data. On some projects I&#x27;ve been able to make do with SQLite only for over a year before having to bother with other databases.<p>However, I always design with the intent to use PostgreSQL or some other database. Sometimes with the intent of using two different data stores in the scaled up version. For instance an SQL database for stuff that has low volumes, and perhaps a time-series database for the high volume stuff.<p>This is why I always design a persistence interface. An internal persistence API layer inside the application. I also write the test suite to this interface. This makes adding support for other databases much easier later.<p>Note that I say &quot;add&quot;, because I usually keep the SQLite support after I&#x27;ve added support for the databases I want to use in production. Keeping SQLite is extremely useful for when people want to do integration testing or even when they are learning to use your server&#x2F;service. Rather than having to fire up a database, people can just run with the built in SQLite. You download and run the binary and stuff just works. It also makes cleanup a lot easier. Not least if you run an in-memory database (use &quot;:memory:&quot; as the DB spec).<p>In the persistence layer I tend to avoid using too much abstraction. The interface is my persistence abstraction. I don&#x27;t need more layers. I think ORMs are incredibly limiting and unnecessary. However, I do use sqlx (Golang) to make the SQLite implementation of the persistence layer less verbose (faster turnaround when figuring stuff out). I usually use it for PostgreSQL too since the performance penalty usually isn&#x27;t significant enough to matter. (If you haven&#x27;t used sqlx before: it is essentially like using the DB driver directly, but with a lot less boilerplate). sqlx is trivial to just rip it out if you think it introduces too much overhead.<p>Usually you will know ahead of time when you potentially need more than one data store. I tend to use SQLite for storing everything during initial development, but the API is usually designed in a way that doesn&#x27;t make it awkward to split the store in two or more domains.<p>I sometimes write storage API middleware. For instance statistics, adapters that can combine different permutations of different storage domains, sharding, throttling, specialized logging etc. I&#x27;ve done ACLs, failover, housekeeping middleware as well, but usually they do not belong in persistence middleware.<p>I never put business logic or &quot;cleverness&quot; in the persistence layer. It should worry about storing and retrieving data.<p>You can probably use SQLite as your database for much longer than you think. And some projects honestly will never need more than SQLite. However, I think that if you start doing sharding, replication and dealing with situations where throughput and concurrency is high, you really want to use something a bit more beefy. You have to think about how much time you&#x27;d spend getting SQLite to do things versus how much effort it is to just fire up database instance(s).
belterover 1 year ago
Just a reminder, that if you have a phone...You are already using SQLite...
评论 #38038918 未加载
dborehamover 1 year ago
s&#x2F;probably&#x2F;probably not&#x2F;
kunleyover 1 year ago
I think it is just an indirect marketing of some fly.io features ;)
评论 #38037974 未加载
评论 #38040165 未加载
评论 #38043051 未加载