'Lite' Databases (Re: sqlite3 and dates)

[memilanuk]

On 02/18/2015 04:03 PM, Ben Finney wrote:

>> Is there anything *good* that sits in between the two extremes of
>> SQLite and PostgreSQL?
>
> What do you need a RDBMS to do, and what do you not need?
>
> The answers to those questions vary hugely between different people (and
> most people probably don't think too deeply about them). They will
> determine what “good” means for your case.
>
>> Is there nothing that amounts to a 'PostgreSQLite'?
>
> PostgreSQL itself fits that mould quite well; it is quite capable of
> serving a small footprint while still offering full concurrency.
>
> I don't know of a free-software concurrent RDBMS which can be considered
> lighter than that. (No, MySQL doesn't count; its concurrency is
> *unreliable* and it commonly loses data silently. Don't use MySQL.)
>
> But perhaps you don't need concurrency? Only you can tell us.
>

At this point... I don't think concurrency is going to be a major 
requirement for what I have in mind.  For one project, only a few people 
will be writing to the DB, and only by a stroke of luck would it be at 
the same time, and it would be very unlikely that they would be 
modifying the same record at the same time due to physical constraints.

For the other... there may be anywhere from 1-10 (maybe more, but 
doubtful) entering data (creating new records for competitors, or 
entering existing competitors in a tournament).  I have a hard time 
picturing that few people stressing a modern computer system enough to 
where SQLite couldn't keep up (thinking web-based interface using Flask 
or something similar).  In the latter case, one of the over-arching 
priorities is that it be easily distributable, as in that people with 
relatively little knowledge of a database be able to set it up and run it.

-- 
Shiny!  Let's be bad guys.

Reach me @ memilanuk (at) gmail dot com