Hacker News new | past | comments | ask | show | jobs | submit login

I do not quite understand the premises:

> Given the complexity

Which complexity? It is the simplest possible widespread, reliable and effective solution. Which makes it a primary choice.

> it seems like there are use cases or needs here that I'm not seeing

On the contrary, the use cases for the traditional Relational DB engines are defined: when you need a concurrency manager better than filesystem access. (Or maybe some unimplemented SQL function; or special features.) Otherwise, SQLite would be the natural primary candidate, given the above.

Edit:

I concur about https://blog.wesleyac.com/posts/consider-sqlite being a close to essential read if one has the poster's doubt.

To its "So, what's the catch?" section, I would add: SQLite does not implement the whole of SQL (things that come to mind on the spot are variables; the possibility of recursion was implemented only recently, etc).




> ... the possibility of recursion was implemented only recently, etc).

Noting that "recently" was August 2014 (version 3.8.6), according to https://sqlite.org/oldnews.html.

The "missing" right/full join types just hit trunk this past week and are still being debugged: https://sqlite.org/src/info/f766dff012af0ea3


> Noting that "recently" was August 2014

Right. This as an issue has little to do with deployment the way the submitter intended, and has to do with software that was implemented using specific static versions of SQLite and that some sometimes use as no better alternative meanwhile emerged. The "delay" is more evident (more "daily present") to said users, and has little to do with new products.

Nonetheless, given that, I would first check which subset of SQL you may need - I am not sure on how much overlapping you have with other mainstream products.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: