[HN Gopher] Why SQLite succeeded as a database (2016)
___________________________________________________________________
Why SQLite succeeded as a database (2016)
Author : Tomte
Score : 295 points
Date : 2020-02-19 16:36 UTC (6 hours ago)
(HTM) web link (changelog.com)
(TXT) w3m dump (changelog.com)
| joshdance wrote:
| We used SQLite at my company to allow users to write SQL queries
| against their db. When we hit the limit of it, we had to switch
| to Postgres. That migration is quite difficult and I wish we had
| used Postgres from the start. 20/20 hindsight but that was my
| first thought.
| kmfrk wrote:
| Do you have any good articles or posts you can think of for
| managing the migration, in case there're some lifesavers out
| there.
| rocmcd wrote:
| Not an article, but I've used pgloader for this purpose in
| the past:
|
| https://pgloader.readthedocs.io/en/latest/
|
| Great tool, I can't recommend it enough.
| jessermeyer wrote:
| Did you use WAL?
| throwaway55554 wrote:
| Were you using an ORM? I ask because most people use database
| switching as a selling point for using an ORM. I'm rather
| indifferent on the matter, but I'm curious.
| kirstenbirgit wrote:
| You still have to migrate the data. I faced the same kind of
| dilemma, but with MySQL, and kind of noped out when I got to
| stuff like [0].
|
| [0] https://stackoverflow.com/a/87531/1210797
| jtdev wrote:
| Ha! This selling point is just one in a miserable litany of
| poor reasons to use an ORM - you absolutely cannot simply
| switch between databases without doing some work to ensure
| that the data is migrated correctly and the SQL statements
| translate properly.
| nomel wrote:
| Yeah, but verification of correctness is much less work
| than implementation.
| jimbokun wrote:
| As an alternative to an ORM, there is another great
| abstraction layer that works across a large number of
| databases. It's called SQL!
| kingbirdy wrote:
| That's true in theory, but unfortunately you can still run
| in to issues when different databases support different
| parts of SQL, and the db you're migrating from has
| different features than the one you're migrating to.
| cjfd wrote:
| Sure, it is simple and that is why people use it.
|
| But I have also run into hard problems using it. Deleting and
| renaming columns is not supported natively. On the internet one
| can find procedures to do that but they generally do not take
| foreign key references into account. Getting this right is a hard
| problem. In the end we had a function that could be used to
| rename or delete a column even without switching off foreign key
| checking but it was not simple and it was not the first iteration
| of said function and earlier iterations caused lots of subtle
| problems, like a column having a default value or not depending
| on whether the database was a new database or was created using
| schema updates.
|
| Use at your own peril.
| acdanger wrote:
| I've never had an issue altering or deleting columns in SQLite.
| Grant it, I've used both Sequelize and SQLAlchemy as ORMs.
|
| But if you're using SQLite for simplicity there's a good chance
| you're not interested writing raw SQL statements either.
| The_Colonel wrote:
| Yeah, I'm using SQLite for simplicity and exactly because of
| that I want raw SQL instead of some leaky complex ORM
| abstractions.
| yread wrote:
| I use EF core and instrument all my queries - if I see a
| slow one I hand optimize it. Best of both worlds I think -
| and I say that as someone who loves to fiddle with SQL.
| The_Colonel wrote:
| Also worst of both worlds - you need to know very well
| both the underlying database (SQL) and also the complex
| leaky abstraction (EF Core) and how are those abstraction
| translated into the SQL.
|
| I'm no ORM hater (use Hibernate daily) but claiming that
| using ORM will simplify working with the database is at
| least misleading.
| oefrha wrote:
| Pretty sure SQLA the ORM has nothing to do with schema
| migration, which is usually handled with alembic, the sister
| project. Not sure about Sequelize.
|
| Now, there's nothing magical about alembic's handling of
| renaming or deleting columns for SQLite; it has to recreate
| the table just like what you would do if you're hand rolling
| the SQL, so it has the same problems.
|
| Details: https://alembic.sqlalchemy.org/en/latest/batch.html
| danso wrote:
| Not disagreeing with your overall point about SQLite's feature
| set, but IIRC, `ALTER TABLE RENAME` was added in 2018, for
| version 3.25.0: https://www.sqlite.org/releaselog/3_25_0.html
|
| (I chime in only to remark that I myself am constantly
| surprised that SQLite continues to add these kinds of features
| - e.g. WINDOW functions were also in 3.25 - long after I had
| accepted their absence as a fact of life)
| dana321 wrote:
| Yeah, its a pity it doesn't have the ability to do anything
| more than alter table statements that add to a schema, having
| to rename the table, create a new schema and copy its
| contents from the old table can be quite a tricky and
| troublesome thing to do if you've got a live system running
| with users on it.
| cjfd wrote:
| Ah, that is interesting. My experiences were before 2018 and
| I had not kept an eye on it, so I did not know this.
| cjfd wrote:
| Ow, but looking at the docs they still do not seem to
| support delete yet.
| jbob2000 wrote:
| TL;DR because it's simple.
| thrower123 wrote:
| I do wonder how much of the time that SQLite is used, that it
| wouldn't be even simpler to just dump things to an XML file.
| lurker458 wrote:
| Here are some considerations why: https://danluu.com/file-
| consistency/
| umvi wrote:
| Is it simple, though? I mean, reading about how they test it[1]
| leads me to believe it is not simple. Maybe it's simple
| compared to Oracle, and maybe _using it_ is simple, but the
| actual implementation is definitely _not_ simple.
|
| [1] https://www.sqlite.org/testing.html
| jbob2000 wrote:
| I don't care about the implementation and I congratulate the
| developers on abstracting all of that complexity away from
| me. That's what good software does.
| umvi wrote:
| I misinterpreted your comment. I thought you were saying
| SQLite was successful because SQlite itself (i.e. the
| implementation) was simple, not because it was simple to
| use.
| wpietri wrote:
| For what it's worth, I use "simple" for talking about the
| complexity of the thing, and "easy" for the user
| experience. Quite frequently easy things have to be
| complex because the cognitive load gets shifted into the
| machinery.
|
| E.g., compared with a Model T, modern cars are much
| easier but much more complex because the car itself
| understands things like adjusting the ignition timing and
| safely getting the motor turning, things that a Model T
| user had to understand if they wanted to avoid getting a
| broken arm before they got out of the driveway:
| https://www.fordmodelt.net/how-to-drive-ford-model-t.htm
| solarkraft wrote:
| It's simple to use.
| umvi wrote:
| Most of the time, yes, if SQLite supports the filesystem
| you are using. If the filesystem doesn't have a particular
| feature SQLite needs, it can be difficult to get working
| the way you want it to.
| danso wrote:
| What scenarios/filesystems lead to these kinds of
| conflicts?
| franga2000 wrote:
| Not exactly a filesystem, but it doesn't work on SMB
| shares, which is an enormous pain in the ass. And I'm not
| even talking about concurrent access - just one user. I
| get that SMB file locking is a mess, but making it a hard
| fail by default was a big mistake IMO as most develoers
| using the library don't make special cases to allow this.
| nomel wrote:
| The documentation is very clear than SQLite over a
| network isn't a good use case, for reasonably sized data.
| Item 1 from "Checklist for choosing the right database
| engine" [1]
|
| > 1. Is the data separated from the application by a
| network? - choose client/server
|
| > Relational database engines act as bandwidth-reducing
| data filters. So it is best to keep the database engine
| and the data on the same physical device so that the
| high-bandwidth engine-to-disk link does not have to
| traverse the network, only the lower-bandwidth
| application-to-engine link.
|
| > But SQLite is built into the application. So if the
| data is on a separate device from the application, it is
| required that the higher bandwidth engine-to-disk link be
| across the network. This works, but it is suboptimal.
| Hence, it is usually better to select a client/server
| database engine when the data is on a separate device
| from the application.
|
| 1. https://www.sqlite.org/whentouse.html
| umvi wrote:
| Well the issue I ran into was that I wanted a SQLite db
| to have one writer and many readers. However, what I was
| seeing was that queries were failing because the DB was
| locked at the time of reading. The solution is to switch
| journaling mode to WAL[1].
|
| However the particular platform I was developing for was
| an embedded system using the JFFS2 filesystem. JFFS2
| doesn't support shared mmap, which is a feature SQLite
| needs for WAL.
|
| So basically, it was big pain - I had to setup a tmpfs
| mount point where the WAL-enabled DB resided and then
| periodically sync it to flash.
|
| [1] https://www.sqlite.org/wal.html
| BubRoss wrote:
| Why didn't you just do more granular writes and let the
| different processes lock the file? SQLite is impressively
| fast, it can handle a lot before you need a full
| database.
| umvi wrote:
| I don't know how to do that.
|
| Basically there is one process periodically dumping stats
| into a sqlitedb. There is an HTTP API that can retrieve
| said stats. How do I make it so the HTTP API doesn't
| occasionally fail when trying to read from the DB?
| gwd wrote:
| I'd say there are a load of reasons, all of which combine
| together to make it unbeatable:
|
| * Simple to embed into you application (no setting up a
| separate database, &c).
|
| * Fantastically backwards compatible
|
| * Public domain (so easy to comply with the license)
|
| * High quality: Reasonably fast, reasonably efficient,
| reasonable feature support.
|
| The lack of any of these would add significant drag. It's
| difficult to imagine any other project catching up and
| displacing it at this point.
| bob1029 wrote:
| I personally cannot see any near term replacement for what
| SQLite offers. In my world, SQLite became the way in which I
| now manipulate a scope of structured data on a single logical
| disk. I mostly view it as a very reliable and friendly layer
| on top of basic file IO which also happens to be compatible
| with virtually every computer on earth. I can copy a SQLite
| database out of an embedded microcontroller environment and
| directly open it on my x86_64 workstation, edit some values,
| and then copy it back down without any fears of compatibility
| issues.
| rhombocombus wrote:
| I came to SQLite recently having used big iron enterprise tools
| for my analytical work previously (namely Oracle), and wow, what
| a lovely elegant tool. It isn't just super useful for web and
| embedded applications, it is quite a powerful and convenient
| analytical tool for quickly ingesting huge flat files and
| querying them.
| AdmiralAsshat wrote:
| The interview transcript is much appreciated! I hate it when
| random two-hour podcast has a 15 minute interview I want to
| listen to, and have to go hunting for it.
| rtkwe wrote:
| Which is a shame because most podcast apps have chaptering
| systems where particular interviews and segments can be easily
| bookmarked. Even without that feature show notes can include
| links and timestamps to particular segments too but many shows
| don't bother because it's extra work.
| vbezhenar wrote:
| While everyone's praising SQLite, I want to note that SQLite type
| system is absolutely horrible. When you can store string in the
| integer column, you don't have a type system. And it's absolutely
| not intuitive for people having experience with other databases.
| senderista wrote:
| I agree, if you want dynamically typed columns then just define
| a separate Any or Variant type. I don't see the point of schema
| if it's not enforced.
| v64 wrote:
| Hipp talks about that in the interview a little bit:
|
| > SQLite really started life as a Tcl extension, Tcl being
| the programming language, the Tcl/Tk. The project I was
| working was working on was written in Tcl/Tk and so SQLite
| began as a Tcl extension and as a scripting language, like
| Perl or Python, where you can put any type of value you want
| in a variable. So a variable might hold a string, a number, a
| byte array or whatever. So I made SQLite the same way, where
| just because you've declared a column of a table to be text
| doesn't mean you can't put integer in there, or just because
| you declared a column in the table to be a short int, why not
| put a 2-megabyte blob there? So what? It'll do that.
|
| > Or if you have a comment that's declared integer and you
| try to put text in it, it looks like an integer and it can be
| converted without loss. It will convert and store it as an
| integer. But if you try and put a blob into a short int or
| something, there's no way to convert that, so it just stores
| the original and it gives flexibility there. And this is
| useful in a lot of cases, because sometimes you just have a
| miscellaneous column in a table that you might need to store
| lots of different things in. And in traditional database
| systems you actually have to have multiple columns, one for
| each possible data type, whereas in SQLite you put it all in
| one column. So it works well.
|
| > And for that matter, with SQLite you don't have to give the
| column a type at all. You can just say, CreateTable T1
| (a,b,c) and then you've got a table with three columns named
| a, b and c and you put whatever you want there.
|
| > Well, it flows directly out of the scripting language
| traditions. You don't declare types for variables in Tcl; you
| didn't used to do it in Python, I guess you can do it some,
| now. You don't do it in JavaScript... You just say it's a
| var.
| zachwill wrote:
| I actually prefer SQLite's take on type affinity:
| https://www.sqlite.org/datatype3.html
| bob1029 wrote:
| SQLite is a wonderful database. We use it in production many
| times over for all of our clients. Not having to worry about
| whatever arbitrary SQL Server installation is available in a
| particular environment has saved us so much time and frustration.
| Combine SQLite with .NET Self-Contained Deployments means that we
| (our automated tools) now copy our software distribution zip to
| target, extract to path, run executable as administrator and walk
| away. Without SQLite we could not do this.
|
| Migrations are also hilariously easy with SQLite if you use the
| user_version pragma. We have a monotonically-incrementing number
| to indicate each version. Our migrator first queries this upon
| startup and runs all the migrations that exist between current
| user_version and whatever our highest sequence # is (defined as a
| constant in code). Some might argue that you should just use EF
| (or whatever language-specific ORM), but I prefer the level of
| control and the substantial performance boost you get with raw
| SQL and a simple migrator approach. I cannot speak for EF Core,
| but EF6 performance was absolutely abysmal in some more complex
| cases.
|
| I would also say that performance might surprise you if you turn
| on WAL. I have saturated NVMe disks inserting lots of data into
| SQLite. The trick is to use a single connection and let SQLite
| handle the serialization for you, rather than try to manage
| multiple connections to the same file in code (i.e. one
| connection per logical operation sucks for SQLite).
| api wrote:
| I came here to say this. It succeeded because it's an
| extraordinarily high quality piece of code!
|
| The 'lite' is even a bit of a misnomer. Properly tuned I've
| seen 1TB+ SQLite databases work just fine. It doesn't scale
| horizontally with CPU cores as well as a "real" database but it
| can perform very well with large data sets if there's only one
| or two writers.
| StreamBright wrote:
| What is the underlying storage structure that scales to TB+?
| pjscott wrote:
| Just regular B-trees for row and index storage. There's a
| reason why it's such a popular data structure!
|
| https://www.sqlite.org/arch.html
| bob1029 wrote:
| If you want TB+, you are talking about multiple computers
| (in context of indefinite scaling).
|
| For most who browse HN that immediately means you reach for
| Postgres (and you would be wise to do so), but I would
| argue you can continue to use SQLite indefinitely (one
| instance per node) if you manage replication and
| transactions between nodes at your application layer.
|
| I realize this is probably beyond what most developers want
| to screw with, but I have seen some extremely promising
| results in experimental implementations of this scheme.
| Being able to replicate items conditionally based directly
| on business needs is a very powerful capability on paper -
| E.g. User session data must be synchronously replicated to
| all nodes, while other entities can by asynchronously
| replicated based on their use cases. You could handle
| replication and transactions based upon any business factor
| or state if you go down this path.
| chaz6 wrote:
| There is a derivative called rqlite which uses the raft
| consensus protocol to give you a highly fault-tolerant
| distributed database.
|
| https://github.com/rqlite/rqlite
| senderista wrote:
| It's a great idea and I'm working on something similar,
| but Raft or any other quorum-based consensus protocol is
| a poor choice for the data plane.
| nbevans wrote:
| There is actually no "lite" word in SQLite. Think of it as
| SQL-ite. The "ite" is a deliberate connotation to
| rocks/geology i.e. granite, magnetite, etc. Make of that what
| you will. This is documented BTW on the SQLite docs.
| spondyl wrote:
| While I couldn't find anything in the docs, there's a
| snippet of a transcript here:
| https://changelog.com/podcast/201#transcript-67
| kohtatsu wrote:
| Another: http://sqlite.1065341.n5.nabble.com/SQLite-
| Pronunciation-td8...
|
| >[...] I think it should be pronounced "S-Q-L-ite". Like
| a mineral. But I'm cool with y'all pronouncing it any way
| you want. :-)
| inferiorhuman wrote:
| _one connection per logical operation sucks for SQLite_
|
| How is this typically handled? Using OS file locking
| primitives?
| zahrc wrote:
| Yes
|
| https://www.sqlite.org/faq.html#q5
| jessermeyer wrote:
| I know SQLite's SQL query engine is implemented as a VM. Are
| there ways of optimizing repeated queries, similar to compiling
| a query to avoid the VM churn? Perhaps more importantly, have
| you ever been disappointed by the query engine's performance?
| nbevans wrote:
| You can "prepare" a SQL statement and use it multiple times.
| I.e. you can use the same VM for a statement many times.
| to11mtm wrote:
| >Some might argue that you should just use EF (or whatever
| language-specific ORM), but I prefer the level of control and
| the substantial performance boost you get with raw SQL and a
| simple migrator approach. I cannot speak for EF Core, but EF6
| performance was absolutely abysmal in some more complex cases.
|
| Look into Linq2Db [1] (Disclaimer, I contribute to the project
| a little bit.)
|
| It's the perfect in-between for if you want LINQ like
| abstractions but don't want the overhead of an ORM, it's more
| like Dapper than, say, EF or NHibernate.
|
| Best of both worlds: I can quickly prototype a design using
| SQLite, and then flip it over to SQL Server/Postgres by
| changing a config string.
|
| EF Core is somewhat improved from EF in some ways (It's faster,
| often as fast as Linq2Db or Raw SQL) but has moved backwards in
| others (lots of stuff still doesn't work right, more
| importantly things that -used- to work in EF6). IMO EF Core
| tries to do too much; It tries to give the same API to
| interface with both Relational and KV stores, and results in
| not being great at either.
|
| [1] https://github.com/linq2db/linq2db/
| bob1029 wrote:
| We exclusively use Dapper for all database access. I have
| zero problems with a few string constants in my services that
| contain the requisite SQL statements for managing my business
| entities against the database. It's really nice having such a
| consolidated context where your SQLite implementations are
| just single partial classes tacked onto the services you are
| providing persistence for.
|
| That is one other point - SQLite has enabled us to do some
| really deep consolidation of our codebase. We generally use
| one SQLite database per business entity or abstraction.
| Users.db, Logs.db, Sessions.db, Settings.db, etc. It allows
| for a truly 100% independent vertical stack (aside from
| coupling against business models) for purposes of developing
| various pieces of business functionality. This is, in my
| view, is the perfect ideal of 'microservice' architecture.
| One big folder called services, one class per 'microservice',
| one SQLite database per class, one collection of mappers per
| class, etc. I honestly feel like we have settled on the
| perfect grain for our codebase structure (at least in C#/.NET
| Core land). The benefit in our world is that instead of HTTP-
| based RPC, we are doing direct method invocation throughout.
| We also use Blazor in order to extend this concept as close
| to the screen as technically feasible.
| miohtama wrote:
| My only grievance, and a blocker, is that SQLite does not
| support decimal numbers, making it less practical to work with
| finance related data.
| webpaymentsguy wrote:
| You probably already heard of storing amount in cents as an
| integer, but it's a pattern worth mentioning if it fits your
| use case.
| marton78 wrote:
| I don't know how it's done in the US, but in Europe
| financial calculations are done with four digits after the
| dot.
| GordonS wrote:
| I've been using SQLite for something like 20 years - how did I
| not know about `user_version` until now?!
|
| I've always added a `schema_version` table with a single row
| containing a single column with the version, so thanks for
| letting me know about this!
| everybodyknows wrote:
| >... they realized that if this is a critical part of their
| infrastructure, they needed to make sure my business was
| sustainable.
|
| >So companies which are typically large companies that really
| depend on SQLite as part of their product, they just pay us an
| annual fee.
|
| >... we are a 100% engineering shop.
|
| An intriguing option for anyone sitting on an original
| infrastructure solution, and looking to turn it into a
| livelihood, with quality of life as first priority.
| danso wrote:
| I remember listening to this when it was recorded and I still
| remember details from it years later - probably my favorite
| Changelog podcast ever. It's obviously very foolish to make
| software choices based on how much you like its creator as a
| person. But Richard Hipp comes off as a guy so likable that
| goshdarnit, I hope his little project succeeds. Jokes aside,
| though, I don't think it's entirely coincidence that SQLite,
| something that is so good and reliable, was made by someone who
| seems so conscientious and thoughtful.
|
| Though I have to admit, I was and am still disappointed to learn
| that the official way to pronounce SQLite is "S-Q-L-ite", i.e.
| "like a mineral".
| eropple wrote:
| Conscientiousness and empathy are rare commodities in software
| development. It's difficult for somebody to get out of their
| own head and consider a problem fresh, and it's not always
| personally rewarding to do so. It's also expensive, if you want
| to back it up with user testing.
|
| You see it, even, in ostensibly public-consumption open-source
| projects, where the goal is clearly not merely to scratch one's
| own itch but to market the project for uptake for this reason
| or that. I feel like SQLite is a great example of what happens
| when a team is able to foster the kind of empathy to really
| understand how the user _wants it to be_.
| barkingcat wrote:
| I pronounce it "ess que lite"
| hazebooth wrote:
| I'll be honest and say that in my head, I think 's-q-l lite'
| [deleted]
| scohesc wrote:
| I thought it was always pronounced "sequel-ite" personally
| sweeneyrod wrote:
| No love for "seekwelitay"?
| 333c wrote:
| This is how I will pronounce SQLite from now on.
| phnofive wrote:
| Eskewellite
|
| Sequelliteh
|
| Squalitee
|
| Cirquerlanite
|
| Diet Seek-well
| larrydag wrote:
| MySQL is the same way. A lot of people say My-sequel but I
| think its supposed to be my-ess-que-ell
| zitterbewegung wrote:
| We need a normal form for pronouncing and naming relational
| databases.
|
| I'm half joking but it might alleviate people from being
| confused.
| wongarsu wrote:
| I thought the norm was to pronounce SQL as "sequel" in
| Microsoft products and "ES-QUEUE-EL" in every other
| context
| WorldMaker wrote:
| The norm is to pronounce it by how likely you think you
| might get yelled at for trademark infringement by a
| holding company of the assets of an old aircraft company:
| https://en.wikipedia.org/wiki/Hawker_Siddeley
|
| The name confusion is all IBM's fault.
|
| > Chamberlin and Boyce's first attempt of a relational
| database language was Square, but it was difficult to use
| due to subscript notation. After moving to the San Jose
| Research Laboratory in 1973, they began work on SEQUEL.
| The acronym SEQUEL was later changed to SQL because
| "SEQUEL" was a trademark of the UK-based Hawker Siddeley
| Dynamics Engineering Limited company.
| zentiggr wrote:
| So that trademark has been un-revivable since 2005...
| long past time to start saying "sequel" for real :)
| DennisP wrote:
| I preferred to call it "Squeal Server."
| somurzakov wrote:
| my-ass-que-ell is the way to go
| ivalm wrote:
| I looked it up, you're right, it is officially my-ess-que-
| ell. This leads to another question, how do you pronounce
| "NoSQL"? I couldn't find a convincing answer on the web. I
| used to say "sequel" for everything SQL related but clearly
| I was wrong.
| MR4D wrote:
| "red iss"
| WorldMaker wrote:
| PostgreSQL is the fun one out because they officially say
| it is Postgres-Q-L.
|
| The "it's always S-Q-L and never `sequel`" is IBM's fault
| and an early trademark infringement issue in computing.
| (IBM was told it couldn't call it "SEQUEL" by an aircraft
| company.)
| degenerate wrote:
| For anyone curious about the trademark infringement, I
| hunted down the excerpt from the book that Wikipedia uses
| as a source (a book called _Databases Demystified_ ) and
| this is what it says in the book:
|
| >> _The forerunner of SQL, which was called SEQUEL (for
| Structured English Query Language), first emerged in the
| specifications for System R, IBM's experimental
| relational database, in the late 1970s. However, two
| other products, with various names for their query
| language, beat IBM to the marketplace with the first
| commercial relational database products: Relational
| Software's Oracle and Relational Technology's Ingres. IBM
| released SQL /DS in 1982, with the query language name
| shortened to "SQL" after IBM discovered that "SEQUEL" was
| a trademark of the Hawker-Siddeley Aircraft Company. When
| IBM released its next generation RDBMS, called DB2, the
| SQL acronym remained. To this day, you will hear the name
| pronounced as an acronym (S-Q-L) and as a word (see-
| quel), and both are considered correct pronunciations._
|
| I was hoping for a bit more interesting or detailed
| story.
| big_chungus wrote:
| I typically go with just "postgres" for phonetic
| pronunciation. Not sure how else it would be done;
| "postgres sequel?"
| bhandziuk wrote:
| Postgres queue ell
| airstrike wrote:
| I go with psql personally
| why-el wrote:
| genuinely not sure if you are joking or not, but that's
| not the same thing as postgres! :)
| jdfellow wrote:
| I've heard Postgres pronounced as if it were French.
| "Postgree."
| andrewflnr wrote:
| I've heard that, but assumed it came from splitting up
| the name as "Postgre"+"SQL"; if you leave off the SQL
| part you get a word ending in E, and "postgreh" can't be
| right, can it? :)
| WorldMaker wrote:
| Which is why I've also heard developers that either
| assumed the 'g' was silent or a transposition problem and
| you get "poster SQL", "postreg SQL", or worst of all
| "posgret SQL".
|
| Somewhere, I believe in an HN comment, I saw a Postgres
| developer say that one of the biggest regrets of the
| project naming was capitalizing that "shared S".
| ferzul wrote:
| i'm weirded out by the fact that i always use the
| "official" pronunciations for all these products
| gavinray wrote:
| Last month I discover NGINX is not pronounced "en-jinx", and
| today I discover SQLite is not pronounced "sequel-light".
|
| 2020 is turning out to be pretty terrible guys.
| barneygale wrote:
| Wait until you hear how 'valgrind' rhymes with 'grinned'!
| lioeters wrote:
| You and me both, my friend.
|
| Apparently I've been using S-Q-L-ite, not S-Q-Lite.
|
| All these years I've been using "Engine-X", not "en-jinx",
| and didn't know it..
| https://www.nginx.com/resources/wiki/community/faq/
| Volundr wrote:
| I only knew it because I had to look up the
| pronunciation. I kept calling it N-G-I-N-X, but could
| never remember the spelling.
| buckminster wrote:
| Sequel-lite here. I know that makes no sense phonetically.
| agumonkey wrote:
| and it does sound like a mineral which is quite in line with
| how I see sqlite.. pretty, timeless and rock solid
| big_chungus wrote:
| I think there's a case for disputing the official
| pronunciation because it's based off an "official"
| pronunciation of SQL. I've heard it ess-queue-elle and
| sequel, but personally side with sequel. It was originally
| called "Structured English Query Language", abbreviated and
| pronounced "SEQUEL"; later shortened to "SQL" but same
| pronunciation. So I figure sequel-ite is a perfectly
| legitimate pronunciation.
| danso wrote:
| That's how I do it. I understand the etymological reasons for
| "S-Q-L-ite", but SQLite is just too ubiquitous in my everyday
| work for me to speak 4 syllables when referring to it.
| cheez wrote:
| And I thought it was S-Q-lite. S-Q-L-ite makes sense though.
| Most consistent.
| airstrike wrote:
| I say S-Q-Lite except I pronounce the S and Q in Portuguese
| and the rest in English...
|
| Luckily I code on my own, so nobody hears this abomination
| out loud
| gdsimoes wrote:
| I do the same thing. Maybe we should talk.
| remmargorp64 wrote:
| I'm still just gonna keep calling it "sequel light".
| krn wrote:
| > Jokes aside, though, I don't think it's entirely coincidence
| that SQLite, something that is so good and reliable, was made
| by someone who seems so conscientious and thoughtful.
|
| The same could probably be said about Redis and Salvatore
| Sanfilippo.
| mrzacsmith wrote:
| I found this fascinating, as a student we are taught to use
| SQLite and then told to use PostgreSQL for production. I am told
| that a large amount of mobile native apps use SQLite. Does anyone
| have any stats on this? Seems like a nice choice, but the
| searches I have done are all over the place.
| me551ah wrote:
| SQLite is a brilliant lightweight database which is available
| everywhere. All mobile OSs support it and it's a breeze to run on
| even embedded Linux. I just wish web browsers would also support
| it and make webSQL a standard, it would make programming for the
| web so much easier.
| hasperdi wrote:
| Actually, it was about to become standards. Some browsers
| implemented it, but then they decided not to go ahead as all
| browsers will have the same SQLite implementation.
| atishay811 wrote:
| It is weird in the hindsight as with just Webkit(which is
| most of blink still) and Gecko, there are just two engines
| left. And when Gecko goes down (which is losing market
| share), this would seem even more stupid. SQL is a standard.
| They could have standardized on it rather than an
| implementation.
| Carpetsmoker wrote:
| SQL is a standard, but SQLite doesn't implement "standard
| SQL", it implements "SQLite SQL".
|
| For better or worse, the web has always been driven by
| specifications, rather than implementations. Properly
| standardizing all of SQLite in a spec is not trivial, and
| as much I think SQLite is great software, I don't think
| that relying on SQLite the library _specifically_ would be
| a good idea. What if the latest version of SQLite does
| something that 's not in the spec or prohibited by the
| spec?
|
| Either way, there's IndexedDB now, which is supported by
| almost everything, including IE.
| Krustopolis wrote:
| Internet Explorer would like to have a word with you. It
| was clearly an "implementation over specification"
| effort.
| nolok wrote:
| > For better or worse, the web has always been driven by
| specifications, rather than implementations.
|
| Surely you're joking ? Having things done by
| specifications first has been extremly rare, pretty much
| everything rather followed the "make the specification
| after the fact to be whatever X browser has done and is
| used". Protocols, markup, css, javascript, the whole
| thing was done by implementation.
| firethief wrote:
| > For better or worse, the web has always been driven by
| specifications, rather than implementations.
|
| What? The specifications document what browsers already
| do. Have you seen the HTML5 spec? It's mostly
| formalization of error-recovery, showing how to interpret
| previously technically-broken documents in the way modern
| browsers have converged on. It's not what anyone would
| design, but there's no one driving.
| 3fe9a03ccd14ca5 wrote:
| Once I discovered SQLite, I never went back. It's so easy. I'm
| still shocked when I see docker compose files that spin up
| entire MySQL dbs when a simple SQLite connector would be so
| much easier!
| williamdclt wrote:
| Whether it is in staging, in dev or in tests, use the same DB
| engine as in prod. It _will_ save your butt sometimes.
|
| Also, my docker-compose for a Postgres container is
| literally: services: db:
| image: postgres:10 ports: -
| "5432:5432"
|
| "so much easier" seems very hyperbolic. Not denying that
| SQLite is an amazing piece of software though!
| jokoon wrote:
| Don't forget about SpatiaLite! Having a GIS-capable lightweight
| database, without relying on a typical DB system is pretty nice
| too.
| Animats wrote:
| Because they took reliability seriously.
|
| If the people who did the original Macintosh "resource fork"
| updater had been serious about maintaining consistency of the
| data structure, that approach would have lasted longer. That was
| a really good idea, badly implemented because they had to cram it
| into 128KB and use a floppy. Unfortunately, it wasn't rewritten
| when the Mac line got more memory and hard disks.
|
| Somebody had to get the open source world past using text files
| for everything.
| outworlder wrote:
| One thing that I wish more people realized, especially ones
| developing native apps, is this: unless you really need an
| specific file format for your application, don't design your own.
| Just use SQLite. You get so much out of it (including features
| like undo), as well as a huge toolkit.
| combatentropy wrote:
| "SQLite does not compete with client/server databases. SQLite
| competes with fopen()." ---
| https://www.sqlite.org/whentouse.html
| jimis wrote:
| > (including features like undo)
|
| Can you please elaborate on this?
| crmrc114 wrote:
| Serious question, how in the heck did the podcasters get their
| transcript? Did they pay someone to edit a machine translation?
| That is one of the coolest things I have never seen for any
| podcast!
| cxr wrote:
| Asked and answered here:
|
| https://news.ycombinator.com/item?id=15251977
| shadowgovt wrote:
| I don't know how they seeded the transcript set (looks like
| this one landed in 2017), but nowadays, transcripts are
| accepted via GitHub.
|
| https://github.com/thechangelog/transcripts
| GnarfGnarf wrote:
| My app had been running on CodeBase (dBase clone from Sequiter)
| for twenty-five years. When we converted to macOS, CodeBase
| wouldn't compile for 64-bit. Panicked, I turned to SQLite.
| Miraculously, we were able to switch in a couple of weeks. It is
| indeed a pleasure to work with. Especially with tools like DB
| Browser to poke around with.
| JTbane wrote:
| It does one thing and does it well.
| janvdberg wrote:
| Meta: this podcast's RSS feed only goes back so far (2018). So I
| have no way to add/listen to this episode in my podcast app?
| jerodsanto wrote:
| We used paged feeds[1] for our RSS, but not all podcast clients
| support it. I might end up going back to a full feed, but
| remove the show notes, etc from older episodes to keep the file
| size smaller...
|
| [1]: https://podlove.org/paged-feeds/
| janvdberg wrote:
| Ok that makes sense. But I use Overcast, so how can I listen
| to it?
| hharnisch wrote:
| For all the great things about SQLite there are some concerning
| things around the project.
|
| First off, even though the source code is public domain, you
| can't contribute since it is closed source:
| https://sqlite.org/copyright.html
|
| There are 3 developers who maintain the project
| https://www.sqlite.org/crew.html and operate under a "code of
| ethics" that used to be called their "code of conduct"
| https://sqlite.org/codeofconduct.html
|
| While it succeeded in getting widely adopted I have trouble
| believing that this is sustainable.
| dekhn wrote:
| they have contracts to support the US military for many decades
| into the future. Hard to be more sustainable than that.
| hharnisch wrote:
| There are 3 people on the planet who can make changes to it
| and one person who can work on their custom made source
| control system. Single points of failure are not sustainable.
| Carpetsmoker wrote:
| Well, it's been popular for 20 years, so that sounds fairly
| sustainable to me. A lot of projects with many more
| contributors have come and gone in that time period.
|
| Either way, that doesn't make it "closed source" like you
| said in the other comment.
| tzs wrote:
| > There are 3 people on the planet who can make changes to
| it
|
| Anyone on the planet can make changes to it and distribute
| those changes. The only thing those 3 can do that the rest
| of us cannot is get their changes into the copies
| distributed at sqlite.org.
| SQLite wrote:
| Just to be clear: We do not have any support contracts with
| the US military, nor any other US government agency, nor any
| other government entity, either inside or outside the US. Not
| that we would turn down such work if it were available, it is
| just that is has never come up.
| dekhn wrote:
| I'm pretty sure I read this in an interview with one of the
| authors. However, I can't find it, so I will defer to you.
| Apologies for the implication.
| otoburb wrote:
| They address this directly under the section entitled "Open-
| Source, not Open-Contribution":
|
| _SQLite is open-source, meaning that you can make as many
| copies of it as you want and do whatever you want with those
| copies, without limitation. But SQLite is not open-
| contribution. In order to keep SQLite in the public domain and
| ensure that the code does not become contaminated with
| proprietary or licensed content, the project does not accept
| patches from unknown persons._
|
| In other words, the reasoning is that since the code is
| released to the public domain, they want to ensure they can
| continue doing so without encumbering or confusing future
| releases with tainted contributions. Quite admirable.
| thrower123 wrote:
| It's unfortunate that they bowed to pressure and removed their
| original monastic code of conduct.
| oefrha wrote:
| Being open source and being open to contributions are pretty
| much orthogonal. SQLite itself is every bit open source.
|
| This isn't even a particularly strange arrangement for open
| source. See _The Cathedral and the Bazaar_.
| jjeaff wrote:
| Huh? The page you linked clearly says "Open Source".
|
| So even if those 3 developers disappear tomorrow, you can fork
| the source code and compile and maintain your own.
|
| https://www.sqlite.org/src/doc/trunk/README.md
|
| And it's already been sustained for 20 years meaning it has
| outlasted the great majority of software projects out there.
| greenshackle2 wrote:
| It's pretty normal for open source projects to refuse
| contributions from anyone who hasn't signed a CLA or something
| similar. The alternative is a legal nightmare.
| [deleted]
___________________________________________________________________
(page generated 2020-02-19 23:00 UTC)