Re: embedded/"serverless" (Re: serverless postgresql) - Mailing list pgsql-general

> > It's not so important to hide the fact that postgres is being used as it
> > is to spare the user from having to know anything about general database
> > administration when the all the app really needs from the db is for it
> > to be a more powerful way of storing and retreiving information from
> > user-owned files.
>
> Installation and upgrades are another issue.
>
> To 'install' a typical embedded database requires no action at all -
> all the infrastructure is embedded within the application, or at most
> a single external dynamica library.

This is by far (other than reliability and compatibility) the most important
thing for me.

> All of this explains why an embedded PostgreSQL isn't a great idea. It
> being a true multi-user database means that even if you went though
> all the work needed to turn it into an embedded database you wouldn't
> get most of the advantages.

Is it true that postgres is not suited for this and should not be used as
such or is it just a matter of spending the time to allow you maybe compile
an embedded version?

> Short term, if you want embedded SQL, use something like SQLite that's
> designed to work that way. If you want to share code between an
> embedded DB and PostgreSQL then use a database agnostic API (such as
> DBI or libdbi) and restrict yourself to fairly vanilla SQL.

This is exactly the approach that I have been using and it has worked very,
very well.  The only problems that I have come across have occured when my
sql just wasn't quite "vanilla" enough.  For instance sqlite doesn't have
date functions.  We have not come across any show stoppers for this approach
but we do have to always consider that we are coding for 2 different dbs and
sometimes we do have to write db specific sql when there are differences and
test on both dbs.  I understand that if that's what I have to do then that's
what I have to do.  It would just be very, very nice to have postgres in
both situations, if it were possible.

> Now, while I think that an embedded fork of PostgreSQL is completely
> missing the point I do think that a low maintenance fork or
> configuration option would be a very useful feature. I'd love to
> be able to ship an application that would
>
>   o Have a private installation of PostgreSQL
>
>   o That would run semi-persistently - if the DB isn't running, the
>     application will transparently start it, and if the DB is idle
>     for some length of time it gracefully shuts down
>
>   o Is zero-maintenance - all vacuuming, analysing etc is handled
>     automatically. So are database version upgrades.
>
>   o That runs under the permissions of the user running the application
>
>   o And that could, by tweaking an application configuration variable
>     could swap out the private PostgreSQL installation and instead
>     access a standard installation

This just might work fine for me.  :-)

> But (apart from the easy DB version upgrade bit) I'd far rather have
> point-in-time or incremental backups, easy replication, richer SQL
> support, easier reporting and easier to use replication. So, much as
> I'd like it, a low maintenance build is a long way down my list of
> priorities.

point-in-time, incremental backups, easy replication would be big for me as
well.  Especially point-in-time and incremental backups