Hacker News Reader

> Zero-configuration is actually quite an onerous design requirement, as it immediately eliminates most features which shouldn't be on by default. It also eliminates tuning.

It also makes for a stupidly easy to use product. SQLite easily outperforms Postgres in default settings and any "optimized" snippets blog posts cough up for the workload generated by a project I'm working on.

I'm seriously tempted to drop support for non-sqlite DB backends, since it's unlikely that the majority our potential customers (SMB environment) could do a better job than that at configuring database servers.

> That's why that page also says "Think of SQLite not as a replacement for Oracle but as a replacement for fopen()".

True.

Point is, most software has only the need for fopen(), but instead uses something like Oracle.

> Zero-configuration ... also eliminates tuning.

Not quite, SQLite can be tuned using pragma's, https://www.sqlite.org/pragma.html which covers most of your tuning needs.

Of course, if RDBMS vendors really cared about compliance with ANSI SQL, swapping out SQLite for Oracle or MS or Postgres would be easy. But they're mostly halfhearted about it.

Including SQLite, to be fair. Its dynamic typing can make for rather nasty surprises if you try to import its data into anything else.

Hrm.[1]

> (3) SQLite lets me insert a string into a database column of type integer!

> This is a feature, not a bug. SQLite uses dynamic typing. It does not enforce data type constraints. Data of any type can (usually) be inserted into any column. You can put arbitrary length strings into integer columns, floating point numbers in boolean columns, or dates in character columns. The datatype you assign to a column in the CREATE TABLE command does not restrict what data can be put into that column. Every column is able to hold an arbitrary length string. (There is one exception: Columns of type INTEGER PRIMARY KEY may only hold a 64-bit signed integer. An error will result if you try to put anything other than an integer into an INTEGER PRIMARY KEY column.)

> But SQLite does use the declared type of a column as a hint that you prefer values in that format. So, for example, if a column is of type INTEGER and you try to insert a string into that column, SQLite will attempt to convert the string into an integer. If it can, it inserts the integer instead. If not, it inserts the string. This feature is called type affinity.

I did not know that.

I am... incredibly horrified.

1) https://www.sqlite.org/faq.html#q3

It's why I don't use SQLite without some sort of ORM layer to do the typechecking and to sanely migrate schema changes.

I guess I don't mean more features. I just mean I want to write the same code and put in heroku or whatever and have it be ready for production load (10,000s or 100,000s of people hitting it).

The code I wrote has already told the machine what I want it to do. I don't want to be involved in figuring out how to make the DB work on a larger load.

Being serverless isn't a feature for me. Zeo-configuration is. Can't it handle the server stuff without asking me to type more lines of code? Maybe on heroku?

If you're into ORMs, then you can do that, use SQLite in dev and switch to PostgreSQL when in prod on heroku.

You're basically bashing the Smartcar because it can't pull your 5th wheel heavy trailer.

I agree with the analogy, but I disagree with "bashing."

I don't think its a failure.

> I just mean I want to write the same code and put in heroku or whatever

> I don't want to be involved in figuring out how to make the DB work on a larger load.

Sqlite definitely wasn't made to fulfill that need of yours. Why do you think it's supposed to give you that?

I agree it wasn't designed to fulfill that need. I have not claimed (anywhere) that it is supposed to.